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