RE: [csmith-project/csmith] 717b1c: Fixed a bug related to --no-math64 and --no-longlo...

["Xuejun Yang" <jxyang@cs.utah.edu>]

There are places the random generator must decide whether a long is 4 bytes or 8 bytes. If you want to make it 4 bytes for all platforms, I have no issue with that.

Generating regular C int types means we are getting rid of safe math functions. Are we ready for that?

-Xuejun

> -----Original Message-----
> From: csmith-commits-bounces@flux.utah.edu
> [mailto:csmith-commits-bounces@flux.utah.edu] On Behalf Of John Regehr
> Sent: Wednesday, May 04, 2011 4:40 PM
> To: csmith-commits@flux.utah.edu
> Subject: Re: [csmith-project/csmith] 717b1c: Fixed a bug related to --no-math64
> and --no-longlo...
> 
> Yes, moving to fixed-width integers would solve the problem we are
> talking about.
> 
> But first, it is unnecessary.  The current framework is perfectly fine
> as long as you don't look at the size of integer types.  Xuejun I will
> keep saying this until I feel like you have understood what I am saying.
>   Am I explaining it poorly somehow?
> 
> Second, going to fixed-width types is counter-productive if we want to
> start generating regular C integer types.  As I said, I think this would
> be preferable anyway.
> 
> John
> 
> 
> 
> 
> 
> On 5/4/11 4:34 PM, Xuejun Yang wrote:
> > This is exactly my solution offers. When printing out the program, out data
> types naturally translate into "int8_t", "int16_t", why do you need to look up
> the platform info?
> >
> > -Xuejun
> >
> >> -----Original Message-----
> >> From: csmith-commits-bounces@flux.utah.edu
> >> [mailto:csmith-commits-bounces@flux.utah.edu] On Behalf Of John Regehr
> >> Sent: Wednesday, May 04, 2011 4:31 PM
> >> To: csmith-commits@flux.utah.edu
> >> Subject: Re: [csmith-project/csmith] 717b1c: Fixed a bug related to
> --no-math64
> >> and --no-longlo...
> >>
> >> The solution is not to look at the host platform.
> >>
> >> Why do I have to keep saying this?
> >>
> >> John
> >>
> >>
> >>
> >> On 5/4/11 4:28 PM, Xuejun Yang wrote:
> >>> As I said, the solution is representing integer types with sizes not names.
> >> Right now we have the following types:
> >>>
> >>>    	eChar,
> >>> 	eInt,
> >>> 	eShort,
> >>> 	eLong,
> >>> 	eLongLong,
> >>> 	eUChar,
> >>> 	eUInt,
> >>> 	eUShort,
> >>> 	eULong,
> >>> 	eULongLong,
> >>>
> >>> Changing them to int8, int16, int32... could eliminate the ambiguity once
> and
> >> forever. It requires a lot of find and replace though.
> >>>
> >>> -Xuejun
> >>>
> >>>> -----Original Message-----
> >>>> From: csmith-commits-bounces@flux.utah.edu
> >>>> [mailto:csmith-commits-bounces@flux.utah.edu] On Behalf Of John
> Regehr
> >>>> Sent: Wednesday, May 04, 2011 4:22 PM
> >>>> To: csmith-commits@flux.utah.edu
> >>>> Subject: Re: [csmith-project/csmith] 717b1c: Fixed a bug related to
> >> --no-math64
> >>>> and --no-longlo...
> >>>>
> >>>> The mistake here was looking at the size of an integer on the host
> >>>> platform.
> >>>>
> >>>> We need Csmith's output to depend ONLY on the command line options
> and
> >>>> seed, not anything else.
> >>>>
> >>>> I want you to make sure this is the case and also explain to me how you
> >>>> made sure.
> >>>>
> >>>> John
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 5/4/11 4:17 PM, Xuejun Yang wrote:
> >>>>> I made the change that letting "long" to have different sizes on different
> >>>> systems. Unfortunately I forget to disable generating "long" integers
> when
> >>>> no-long-long is enabled.
> >>>>>
> >>>>> If we want to remove the ambiguity, we need to internally represent our
> >>>> integer types with sizes but not names.
> >>>>>
> >>>>> -Xuejun
> >>>>>
> >>>>>>
> >>>>>> Please explain in more detail.
> >>>>>>
> >>>>>> The question is: What does the size of a "long" have to do with
> Csmith's
> >>>>>> decision whether or not to emit code containing the string "int64_t"?
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 5/4/11 4:03 PM, Yang Chen wrote:
> >>>>>>> On x86_64, long is 64 bits. I only considered long long before I fixed
> >>>>>>> the bug.
> >>>>>>>
> >>>>>>> - Yang
> >>>>>>>
> >>>>>>> John Regehr wrote:
> >>>>>>>> Can you explain this bug?
> >>>>>>>>
> >>>>>>>> John
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 05/04/2011 02:56 PM, noreply@github.com wrote:
> >>>>>>>>> Branch: refs/heads/master
> >>>>>>>>> Home: https://github.com/csmith-project/csmith
> >>>>>>>>>
> >>>>>>>>> Commit: 717b1c973636333440d908fd6caa7111b8ccc285
> >>>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/csmith-project/csmith/commit/717b1c973636333440d908f
> >>>>>> d6caa7111b8ccc285
> >>>>>>>>>
> >>>>>>>>> Author: Yang Chen<chenyang@build3.cs.utah.edu>
> >>>>>>>>> Date: 2011-05-04 (Wed, 04 May 2011)
> >>>>>>>>>
> >>>>>>>>> Changed paths:
> >>>>>>>>> M runtime/csmith.h
> >>>>>>>>> M src/OutputMgr.cpp
> >>>>>>>>> M src/Probabilities.cpp
> >>>>>>>>> M src/Type.cpp
> >>>>>>>>>
> >>>>>>>>> Log Message:
> >>>>>>>>> -----------
> >>>>>>>>> Fixed a bug related to --no-math64 and --no-longlong
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >