[csmith-dev] Alignment of struct members cause target dependent checksum

[Yang Chen]

On 6/12/13 5:21 AM, Kees Bakker wrote:
> On 05-06-13 19:16, John Regehr wrote:
>>> Incidentally, John, I was also surprised that Csmith would generate
>>> code that writes to a union member and then reads back from a
>>> different (and not even equivalent) member. On reflection I agree this
>>> might be useful, but shouldn't there at least be a command-line switch
>>> to prevent Csmith from generating undefined behavior? (If Kees
>>> described the problem correctly, the test program was definitely UB.)
>>
>> This is one of those things that is technically undefined but common 
>> compilers (at least GCC and Clang, probably more) provide 
>> well-defined behavior that we wanted to test.  In other words, the 
>> GCC developers guarantee that type punning via union works "as 
>> expected."  In fact, there are optimization passes that propagate 
>> values through these sorts of type puns (I'm actually working on a 
>> blog post about this).
>>
>> There are a few random union-related command line options, I'm not 
>> sure if the one you want is there, but if it's not I would imagine 
>> that we could add it.  We spent quite a bit of time on unions!
>>
>> John
>
> Can you perhaps explain what this option does?
>
>   --union-read-type-sensitive | --no-union-read-type-sensitive: allow 
> | disallow reading an union field when there is no risk of reading 
> padding bits (enabled by default).

Basically, when --no-union-read-type-sensitive is passed, Csmith's code 
generation will compares the size of each union field, and makes sure no 
read access to the possible padding bits. For example, let's say we have:

union U1 {
   int f1;
   short f2;
};

Then any read to f1 would be forbidden if f2 has been written.

- Yang