This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets


On Tue, 3 Sep 2013 21:20:04, Joseph S. Myers wrote:
> On Tue, 3 Sep 2013, Bernd Edlinger wrote:
>
>>>> The trouble is that AAPCS semantics are incompatible with the default GNU
>>>> semantics for non-packed structures as well - AAPCS
>>>> strict-volatile-bitfields is only compatible with --param
>>>> allow-store-data-races=1, which is not the default for any language
>>>> variant accepted by GCC (and I say that the default language semantics
>>>> here should not depend on the target architecture).
>>>
>>> As I said it should be easy to fulfil AAPCS requirements if they do not violate
>>> language constrains during code generation and thus warn about accesses
>>> that are emitted in a way not conforming to AAPCS (a warning at struct
>>> declaration time would be nicer, but I guess requires more coding and thought,
>>> though at the point we compute DECL_BIT_FIELD_REPRESENTATIVE in
>>> stor-layout.c would be a suitable place).
>>>
>>
>> Just to make that clear, Sandra's patch tries to follow the AAPCS requirements,
>> _even if_ they violate the language constraints.
>>
>> Thus -fstrict-volatile-bitfields implies --param allow-store-data-races=1.
>
> And my concern is specifically about the defaults - the default for ARM
> should be the same C/C++ language as on other targets - rather than what
> happens if someone specifies -fstrict-volatile-bitfields explicitly.
>

I fully agree with you, the current default state of -fstrict-volatile-bitfields
should be disabled for all targets. That will be changed in part 4 of Sandra's patch.

For portability of application code, the default should be always off, unless
specifically requested.

Even driver code rarely uses bit-fields for register access, because that is
inherently non-portabe. Reason: the bit positions are completely different
on little- and big-endian targets. Most drivers I have seen use some macros
and explicit bit operations for register accesses.


> --
> Joseph S. Myers
> joseph@codesourcery.com 		 	   		  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]