On Mon, 17 Jun 2013 13:38:05 +0200
Richard Biener <richard.guent...@gmail.com> wrote:
> On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
> <jul...@codesourcery.com> wrote:
> > On Mon, 17 Jun 2013 13:12:09 +0200
> > Richard Biener <richard.guent...@gmail.com> wrote:
> >
> >> On Sun, Jun 16, 2013 at 9:26 PM, Jakub Jelinek <ja...@redhat.com>
> >> wrote:
> >> > On Sun, Jun 16, 2013 at 01:08:12PM -0600, Sandra Loosemore wrote:
> >> >> This patch fixes the PR23623 regression. In conjunction with
> >> >> part 2 of the series, it also fixes the new
> >> >> volatile-bitfields-3.c test case.
> >> >>
> >> >> As I noted in previous discussion, there might be a better
> >> >> place to accomplish this effect, but hacking
> >> >> DECL_BIT_FIELD_REPRESENTATIVE can't work because the
> >> >> volatile-ness may be coming from a qualifier on the pointer or
> >> >> object from which the field is being extracted, rather than
> >> >> from a volatile qualifier on the bit field decl. I think the
> >> >> choices are to do it in get_bit_range (as in this patch), in
> >> >> the callers of get_bit_range, or at the places where the bit
> >> >> range information is being used.
> >> >
> >> > So does this means you just always violate C++11 memory model
> >> > requirements with -fstrict-volatile-bitfields? That doesn't seem
> >> > to be a good idea.
> >>
> >> Yeah, it's not clear to me that this patch fixes anything by
> >> design. It mainly changes things from limiting the access in some
> >> way to not limiting it at all ...
> >
> > IIUC, the incompatibility between the specified
> > -fstrict-volatile-bitfields behaviour and the C++ memory model is a
> > recognised deficiency in the ARM EABI. It might be an unpopular
> > suggestion, but how about disabling the option by default for C++ on
> > ARM [*]? Maybe even with a "sorry" if the user tries to turn it on
> > manually?
>
> How are they incompatible? As far as I understand the
> -fstrict-volatile-bitfields
> at most restricts the size of the access further, no? Can you write
> down an example that shows the incompatibility? (woudl be nice to
> see that as comment before the relevant code).
Well -- I'm certainly no expert on the C++ memory model, but I am under
the impression (that I can't seem to verify by googling ;-)) that
accesses to adjacent bitfields during volatile access of a particular
bitfield are forbidden. So simply, for the following:
struct foo {
int a : 8;
int b : 8;
int c : 16;
};
volatile struct foo x;
void bar (void) { x.b++; }
to satisfy the ARM EABI, 'bar' will access all three of a, b and c
using read-modify-write (using int-sized accesses). IIUC for the C++
memory model, only 'b' may be accessed, e.g. using byte-sized
loads/stores.
I'm quite prepared to be wrong though, in which case sorry for the
noise :-).
Julian
