On 06/19/2013 05:10 PM, Joseph S. Myers wrote:
I don't think it's right to depend on the standard version like this. The existing semantics for GNU C and C++ follow the memory model for all standard versions, and that's the sort of thing that shouldn't depend on the target architecture. In the absence of explicit -fstrict-volatile-bitfields, semantics conflicting with the memory model should only be enabled by one of the --param options to allow data races, and not by some default option relating to something in a target ABI that's incompatible with the normal language semantics.
Hmmmm. Well, I'm willing to hack up a patch to remove -fstrict-volatile-bitfields from the defaults for all backends, if it is the consensus of the GCC community to do that and it unblocks consideration of the other wrong-code bug fix patches in the series.
I'm concerned, though, that we should consider the perspective of GCC users on the affected targets as well as that of a standards committee member. E.g., suppose I am an ARM user with some code manipulating memory-mapped I/O registers that was originally developed with an older version of GCC, or with a different compiler. Maybe it is not even my own code, but something I got from a chip vendor SDK. People working with such target-specific, low-level code are far more likely to be familiar with and conforming to ARM's published guidelines for volatile bit-field access than obscure details of a language standard that is not even being selected as the dialect for compiling the code. I think there's a good argument here that by retroactively applying the C11/C++11 memory model to older standard versions, GCC has simply broken access to memory-mapped registers on ARM. After all, the AAPCS predates these newer standards and older versions of GCC at least made an effort to implement the behavior AAPCS required, and if the pr23623 testcase had been added at the time that issue was originally resolved back in 2006, the regression would have been caught immediately when the bitfield range patches were committed.
I hope that by the time GCC switches to C11 and C++11 as its default dialects, ARM will have revised its ABI or clarified how this conflict should be resolved. :-)
Anyway, what do other people think? -Sandra
