[cxx-mem-model] bitfield tests

Aldy Hernandez aldyh@redhat.com
Wed Mar 30 14:41:00 GMT 2011


>> So... do you have any important targets in mind, because I don't see this
>> being a problem for most targets?  As can be expected, I am only interested
>> in x86*, powerpc*, and s390, especially since a cursory glance on other
>> important targets didn't exhibit any problems.  However, given my target
>> bias, I am willing to look into any important targets that are problematic
>> (I'm hoping none :)).
>
> Well, I'm not sure that strict-align targets that provide byte access do
> not simply hide the issue inside the CPU (thus, perform the read-modify-write
> there and do not guarantee any atomicity unless you ask for it).  It might
> be even worse - targets might not even guarantee this for shared cache-lines
> (for non-ccNUMA architectures).  But I'm no expert here, but certainly
> every possible weird CPU architecture has been implemented.

Whoops, sorry I missed your off-list followup from yesterday (I'm 
reading mail sequentially :)):

 > Richard Guenther said:
 > strict-align targets will end up doing read-modify-write operations on
 > word-size even when accessing single bytes.  Note that some CPUs
 > have byte store operations but they usually are not guaranteed to
 > be "atomic" (thus, they simply do the read-modify-write in the CPU).
 > I am not aware of any strict-align CPU that can do atomic byte stores.
 >
 > Obvious problem when for example having multiple non-word-size
 > global vars (unless you force them to word-alignment).

I was not aware of how this played out internally.  This is certainly a 
problem.  I will hunt down hardware for at least arm, sparc, and ia64, 
and investigate.  But it may be that the only option will be to disallow 
the C++ memory model on strictly aligned hardware, or perhaps force 
word-alignment.

Is forcing word-alignment too big of a hammer, or will the users for 
these architectures be content with having no support for the C++0x 
memory model?

Aldy



More information about the Gcc-patches mailing list