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


> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
> Date: Wed, 4 Sep 2013 10:15:22 +0200

> 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.

Counter-observation, FWIW: most drivers I work on (...) use
bit-field structures filled to capacity of the I/O access size
(almost always 32 bits), read and written volatile as the full
structure.  None of the I/O accesses are per *individual*
bit-field, so this particular discussion does not apply, but I
very much would like a warning for unportable code (meaning:
across targets and ABIs within gcc).  The bit-field-structure
declarations are in turn generated by a (supposedly :)
target-endian-aware generator from an I/O register description
(also layout-aware except all intended targets have a common
layout for the declarations used).  If both-endian declarations
were desirable, both could easily be generated and selected #if
THATENDIAN-style.

Not my idea but I dare defend it: using bit-field syntax is
quite a bit more readable than shifting-and-masking macros.
Unfortunately, sometimes there's a gcc-bug or two, tree-sra
being a usual suspect. :/

brgds, H-P


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