[csmith-dev] testing C++11 struct rules

[John Regehr]

My main goal is to catch races introduced by the compiler.

The last time I checked (in Dec) G++ would introduce races on struct 
fields even when given all of the C++ memory model flags.  I suspect 
it's going to take them some time to iron out all of the latent 
incompatibilities between GCC and the new memory model, and my thought 
was that random testing could accelerate that process.

Xuejun, your static information about field accesses is going to be 
rather pessimistic.  This might be OK for bug-finding, but it'll make it 
less effective.  Can you think of any non-pessimistic way (dynamic, I 
mean) to figure out which struct fields are touched by a random program?

John



On 5/13/12 7:28 AM, Derek M Jones wrote:
> Xuejun,
>
>> I think your padding code wouldn't be able to detect the race-introducing
>> transformation John is going after, provided the compiler masks other
>> fields
>> properly when reading/writing a struct field.
>
> I may have misunderstood, but I think John wanted to get at information
> that enabled the random programs to be transformed so that they did not
> contain potential race inducing faults.
>
> The transform I suggested lets such faults exists and provides a means
> of detecting them.
>
> The PADDING transformation will double the compile/execution time, which
> might not be a cost effective way of finding race conditions. But the
> only more efficient technique I can think of is to analyse the generated
> assembler.
>
>>
>> -Xuejun
>>
>> -----Original Message-----
>> From: csmith-dev-bounces at flux.utah.edu
>> [mailto:csmith-dev-bounces at flux.utah.edu] On Behalf Of Derek M Jones
>> Sent: Friday, May 11, 2012 6:15 PM
>> To: csmith-dev at flux.utah.edu
>> Subject: Re: [csmith-dev] testing C++11 struct rules
>>
>> John,
>>
>>> In effect the standard is mandating byte addressing. Writing a C++11
>>> compiler for a machine that cannot address bytes would be quite tricky.
>>
>> The C Standard defines a byte as the smallest unit of addressable
>> storage.
>> So all machines can address C bytes :-)
>>
>> On one of the first 64-bit Cray machines the addressable byte was
>> 64 bits and they did some weird stuff to subdivide this into
>> 8 bit chunks (whose technically correct name is octet).
>>
>>> The question is: how to find these bugs most effectively?
>>
>> The definition:
>>
>> > struct { char a,b,c,d; } s;
>>
>> needs to become:
>>
>> #if BLAH
>> #define PADDING(p)
>> #else
>> #define PADDING(p) p[10]
>> #endif
>>
>> struct {
>> char a,PADDING(x),b,PADDING(y),c,PADDING(z),d;
>> } s;
>>
>> and then you compile and run the program with BLAH being true/false. The
>> results should be the same.
>>
>> You will probably have to do extra stuff to try and stop the optimizer
>> reordering fields around the padding.
>> Taking the address of one or more fields and using it in some weird
>> and hard
>> for the compiler to figure out way ought to do it.
>>
>