> I'm curious; do all the test cases included in > http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html > work for you on those targets as well (without applying the rest of the > patch)?
Not all of them can work, because they describe something that can't be done in hardware. For example, the first test has an incomplete bitfield - the fields do not completely describe an "int" so the structure is smaller (one byte, according to sizeof()) than the access type (2-8 bytes). Looking through the tests, most of them combine "packed" with mismatched types. IMHO, those tests are invalid. > > Either way, if -fstrict-volatile-bitfields does not do what it's > > supposed to do, the correct action is to fix it - not to disable it on > > targets that rely on it for correct operation. > > Unfortunately, "fixing" -fstrict-volatile-bitfields to conform to the > AAPCS breaks conformance with the C11/C++11 standards, The global default is -fno-strict-volatile-bitfields. The flag was added specifically to force the compiler to always use the user-specified type when accessing bitfields, at least when it was physically possible. I don't see why there's a problem. Without the flag, you follow the standard. With the flag, you do what the user told you to do. It's up to the targets to decide which way the flag defaults if the user doesn't specify. For my targets, the default must be to do what the user told you to do, regardless of the standards, because the standards lead to hardware failure. > Meanwhile, while we're bickering about what the default should be, > ARM users (in particular) are stuck in a situation where GCC's > default behavior is to generate unaligned accesses that fault at > runtime or wrong code that silently truncates bitfields, Note that if the user defines a structure that intentionally mixes types in a hardware word, the compiler can't "do what it's told". It's still up to the user to write well-defined structures in those cases. Mixing packed, incomplete bitfields, and multiple types, (i.e. pr48784-1.c in that patch) is an example of a case where gcc can't do what the user asked, because what the user asked is nonsense. > and there is *no* command-line option or even build-time option they > can provide to make GCC generate code that is correct according to > the AAPCS. At the time I added -fstrict-volatile-bitfields, the ARM maintainers seemed to agree that the new functionality was what they needed. So, -fstrict-volatile-bitfields *is* that command line option, it's just either broken for them, or they're trying to do something not physically possible. > But, looking at it practically, I think the battle over > "correctness" was already over when the C and C++ standards > committees voted to specify this behavior in a particular way, and > that in time ABIs that specify some other behavior are going to be > either revised or considered archaic or obsolete. My problem isn't some arbitrary ABI, it's a hardware peripheral register that just can't be accessed in the wrong mode, because the peripheral won't work if you do that. Most MCU peripherals work this way. Just reading a byte or word outside the intended one could have real consequences in the hardware. > About the only way forward I can see is if the GCC steering > committee steps in with a general policy statement about what to do > when language standards conflict with a target ABI. I've not objected to fixing -fstrict-volatile-bitfields, or making the -fno-strict-volatile-bitfields case match the standard. I've only objected to breaking my targets by making that flag not the default.
