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

[Derek M Jones]

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.
>

-- 
Derek M. Jones                  tel: +44 (0) 1252 520 667
Knowledge Software Ltd          blog:shape-of-code.coding-guidelines.com
Source code analysis            http://www.knosof.co.uk