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

[Xuejun Yang]

Just realized the information is already there in the random programs:
Before printing a function, Csmith prints which global variables are written
by that function, and that is field-sensitive. It's not too hard to deduce
from that which fields of which global structs are never written to.

-Xuejun

-----Original Message-----
From: csmith-dev-bounces at flux.utah.edu
[mailto:csmith-dev-bounces at flux.utah.edu] On Behalf Of Xuejun Yang
Sent: Friday, May 11, 2012 5:22 PM
To: 'John Regehr'; csmith-dev at flux.utah.edu
Subject: Re: [csmith-dev] testing C++11 struct rules

Yes, I will make Csmith output the struct-field usage info in a file
separate from the random program. It shouldn't be too hard.

-Xuejun

-----Original Message-----
From: csmith-dev-bounces at flux.utah.edu
[mailto:csmith-dev-bounces at flux.utah.edu] On Behalf Of John Regehr
Sent: Tuesday, April 24, 2012 9:06 AM
To: csmith-dev at flux.utah.edu
Subject: [csmith-dev] testing C++11 struct rules

C++11 (and C11 for that matter) require that races are not introduced by
accesses to disjoint struct fields.  So consider this struct:

struct { char a,b,c,d; } s;

If I clear s.a, it is illegal for the compiler to generate code that 
loads the entire word, masks off a, and stores it back, because this 
introduces races with threads that might be accessing b, c, and d.

In effect the standard is mandating byte addressing.  Writing a C++11 
compiler for a machine that cannot address bytes would be quite tricky.

Anyhow, the problem is that compiler really want to do load/store 
widening.  G++ currently contains bugs of this form; my guess is that 
many of these are lurking in common compilers due to the large amount of 
code that deals with memory accesses and such.

The question is: how to find these bugs most effectively?

Here's what I think we want:

- Csmith outputs a list of struct fields that it touches (or perhaps 
better, doesn't touch).  If it turns out that our programs usually touch 
all fields of generated structs, we'll need to hack it to random not 
touch some fields.

- Yang's Pin tool prints a count of how many times each byte of each 
struct was touched

Now a simple computation suffices to find compiler bugs.

Xuejun, is this something you can add?  Yang, can you add this to your 
queue, to hack on the Pin tool a bit?

John