This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PING: Default to -fstrict-volatile-bitfields for ARM EABI
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rguenther at suse dot de
- Cc: gcc-patches at gcc dot gnu dot org, jie at codesourcery dot com, nickc at redhat dot com, paul at codesourcery dot com, Richard dot Earnshaw at arm dot com
- Date: Mon, 25 Oct 2010 17:13:10 EDT
- Subject: Re: PING: Default to -fstrict-volatile-bitfields for ARM EABI
- References: <4CC0EA53.4070100@codesourcery.com> <alpine.LNX.2.00.1010221139020.23074@zhemvz.fhfr.qr>
> Why is the stor-layout.c part necessary? Why does it not possibly
> cause layout changes? I'm not very familiar with the stor-layout.c
> code, and given that questions I think I'm not the right person
> to review this patch.
Jie asked me to look at this since I originally wrote much of the relevant
code in stor-layout.c. The proposed change certainly *can* cause layout
changes, but only in rather pathological circumstances (perhaps only in the
case of a one-field record, but I'm not certain).
However, I don't understand this patch either, mostly because I'm not sure
exactly what -fstrict-volatile-bitfields is supposed to do (I find the
documentation confusing).
If I have an 8-bit bitfield, aligned on a byte boundary, that's volatile, I
would expect an 8-bit insn to be used to access it, assuming the hardware
has such. Unless I'm missing something, it seems to be that this patch
would *decrease* the chance of that happening, not increase it. So I too
am confused.