This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch 3/5] don't restrict bit range for -fstrict-volatile-bitfields
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Julian Brown <julian at codesourcery dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Sandra Loosemore <sandra at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 17 Jun 2013 14:37:12 +0200
- Subject: Re: [patch 3/5] don't restrict bit range for -fstrict-volatile-bitfields
- References: <51BE0D1C dot 9070404 at codesourcery dot com> <20130616192653 dot GP2336 at tucnak dot redhat dot com> <CAFiYyc0TVzU=QS1BabX6jtoR5Yjt_GKn-Gk5B_0GcowR7Dn9dw at mail dot gmail dot com> <20130617123120 dot 7451adb3 at octopus> <CAFiYyc0+KtUTZ1FG_rFFTSrWY2YGPJ_ZXsnf=NkTR4VskicTvg at mail dot gmail dot com> <20130617132738 dot 30d4aad3 at octopus>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Jun 17, 2013 at 01:27:38PM +0100, Julian Brown wrote:
> 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++; }
I believe in the above it is ok in C++ memory model if the RMW cycle is
using 32-bit type, but in
struct foo {
int a : 8;
int b : 8;
char c, d;
};
volatile struct foo x;
void bar (void) { x.b++; }
it is not (but it is laid out the same), because modification to x.a or x.b
must not create data races on x.c and/or x.d.
Jakub