[csmith-dev] testing C++11 struct rules
Xuejun Yang
jxyang at cs.utah.edu
Fri May 11 18:22:17 MDT 2012
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
More information about the csmith-dev
mailing list