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 :-(
