On 09/25/2013 07:23 AM, Bernd Edlinger wrote:
Richard: I do not know, is this a political issue, that is blocking
the whole of Sandra's patch?
Actually we (softing.com) do not really care what happens to the
default setting of -fstrict-volatile-bitfields. Maybe you could look at
reviewing Sandra's part 1,2,3 independently of the rest?
I can't speak for all of Mentor Graphics, but I personally do not really
care what the default setting of -fstrict-volatile-bitfields is, either.
Looking at it from our customers' point of view, though, this option
currently causes code to be generated that is just broken and wrong and
not conforming to either AAPCS or the C11/C++11 memory model. And
because it's enabled by default on ARM, that means GCC generates broken
code by default on ARM. I think users would rather live with having to
pass -fstrict-volatile-bitfields explicitly than to have a default that
is not useful in any way.
BTW, it was pointed out to me offline that there is precedent for GCC
choosing to ignore details of a target-specific ABI in favor of uniform
behavior across targets -- see the rant against unsigned bit-fields here:
http://gcc.gnu.org/onlinedocs/gcc/Non_002dbugs.html#Non_002dbugs
Anyway, I am hoping that we can reach some closure on this issue before
it is too late to get the fix into GCC 4.9. It's very frustrating to me
that I have been working on it since May or June, tried hard to
incorporate all the feedback I received on the initial patches, spent a
lot of time testing, etc.... and the whole process just seems stuck. :-(
-Sandra
