On 10/16/2013 05:46 PM, DJ Delorie wrote:

As it looks like, the -fstrict-volatile-bitfields are already totally broken,

I tested your example on rl78-elf, with and without
-fstrict-volatile-bitfields, and it generates correct code with it and
incorrect code without it.  Same for m32c-elf.  Same for h8300-elf.
Seems to be working OK for me.

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)?

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, and we seem to be at an impasse where global reviewers refuse to consider anything that breaks language standard conformance and target maintainers refuse to consider anything that breaks ABI conformance. 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, 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.

FWIW, I don't care much myself in an abstract way about whether language standard conformance or ABI conformance should rule here. 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.

Anyway, at this point I've given up on thinking either side is going to convince the other in this debate, and I haven't seen much evidence that either side would be willing to compromise, either (e.g., Bernd's patch to add warnings in cases where the behavior differs, or my earlier proposal to make the defaults depend on the selected language standard as well as the ABI, don't seem to have placated either side). 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. And, of course, the patch itself still needs review....

-Sandra, who is feeling pretty discouraged about how hard it is to contribute to GCC :-(

Reply via email to