[llvm-commits] [llvm-gcc-4.2] r46726 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp

Duncan Sands baldrick at free.fr
Sat Feb 9 13:24:19 PST 2008

Hi Devang,

> > I can't help feeling that a bitfield load or store should touch the
> > minimum amount of bytes possible: only those that contain some part
> > of the bitfield.  In some situations touching other bytes could be
> > fatal, for example if the type is overlaid on some memory mapped io
> > region, or multiple threads are accessing different parts of the
> > type simulteneously.
> I do not think this is required as part of current C ABI. This is  
> responsibility of programmer who is using threading.

the current LLVM implementation means that anyone using threading needs
to not do bitfield accesses, since the compiler generated code could
cause trouble.  Are you suggesting that users should roll their own
bitfield code (I'm not saying that this is unreasonable)?

> >  In the above example you could try accessing
> > d using 4 bytes starting from b, but this would give wrong results
> > if some other thread was accessing b at the same time.  I'm fairly
> > sure that Ada has quite strict requirements about this, and I have
> > the vague idea (I don't know where I got it from) that there is talk
> > of requiring a minimum disturbance rule of some kind in C.
> However what about huge amount of existing C code and other tools that  
> do not enforce this ?

I don't understand what you mean: I'm talking about making the compiler
more strict in the code it generates for bitfield accesses.  As such it
cannot have any impact on correctness of existing C code (though it might
make it run more slowly).

As for Ada, the mainline front-end seems to claim that two record fields
that do not share a common byte can be safely accessed by multiple threads
without synchronization [*].  So it seems that the Ada f-e at least would
like bitfield accesses to only touch the minimum number of bytes.  By
implication it means that gcc bitfield accesses have this property (I will
do some experiments to check).



[*] The language reference manual says (9.10 Shared Variables):
"If two different objects, including nonoverlapping parts of the same object,
are independently addressable, they can be manipulated concurrently by two
different tasks without synchronization. Normally, any two nonoverlapping objects
are independently addressable. However, if packing, record layout, or Component_Size
is specified for a given composite object, then it is implementation defined whether
or not two nonoverlapping parts of that composite object are independently addressable."

Thus it is implementation defined whether two bitfield accesses are independently
addressable (this falls under the record layout exception).  However implementations
are required to document how they define implementation defined things.  The documentation
for the gcc Ada front-end says:

"27. Whether or not two non overlapping parts of a composite object are independently
addressable, in the case where packing, record layout, or Component_Size is specified
for the object. See 9.10(1). Separate components are independently addressable if they
do not share overlapping storage units."

A storage unit is Ada terminology for a byte.

More information about the llvm-commits mailing list