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? The assumption behind that idea is that people who most care about the EABI-specified behaviour (to access hardware registers, etc.) are probably using bare metal and plain C. The downside is the potential for "surprise" for users though, I suppose. Julian [*] Or some other variant target-dependent hack, like depending on -ansi, bare-metal vs. $operating system, etc....
