[llvm-commits] [llvm-gcc-4.2] r100632 - /llvm-gcc-4.2/trunk/gcc/llvm-types.cpp

[Jakob Stoklund Olesen]

On Apr 7, 2010, at 10:02 AM, Duncan Sands wrote:

> Hi Jakob,
> 
>> For example, this struct:
>> 
>>   struct S {
>>     int a, b;
>>     void *c;
>>     unsigned d : 8;
>>     unsigned e : 8;
>>   };
>> 
>> used to be:
>> 
>>   %struct.S = type { i32, i32, i8*, i8, i8 },
>> 
>> but now it becomes:
>> 
>>   %struct.S = type { i32, i32, i8*, i16 }
> 
> this means that you can't write S.d and S.e separately, so if one thread is
> writing to S.d while another writes to S.e then you are in trouble.  Also, if
> this type is describing a memory mapped I/O region then writing or reading both
> d and e when the original code only touches one of them is bad.  I appreciate
> that the C standard doesn't require this kind of thing to work, but I'm pretty
> sure the Ada standard does [*].  (That said, what llvm-gcc did before was
> already broken for Ada, due to this kind of thing).

You want atomic bitfield access??

It sounds to me like the Ada front end should convert bit fields to integer fields if they require atomic access.

Did it work before? The code generated for the example above used 32-bit loads and stores before my change.

> [*] The Ada standard requires reads and writes marked atomic to be rejected
> as an error by the compiler if it isn't able to turn them into appropriate
> atomic processor operations.  The Ada front-end "knows" what kinds of things
> gcc will turn into atomic operations, and so knows what it has to reject.
> Unfortunately llvm-gcc doesn't make exactly the same decisions...

So the model goes from broken to broken with this change. That's not a regression ;-)