[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-02 
11:08:56 UTC ---
(In reply to comment #9)
> OK, my minimal test case removed the "volatile" keyword by mistake.
> 
> The real code in BTRFS has the volatile for the lock value which precedes the
> bitfield, so the corresponding structure would be:
> 
> struct x {
>     long a;
>     volatile unsigned int lock;   /* <- note the "volatile" here */
>     unsigned int full : 1;
> };
> 
> Now, GCC should honour that the value of "lock" can change any time, so it 
> must
> not assume that writing back the same value a few cycles later is safe.

volatiles on single structure members is of course under- (or even
un-)specified.  Consider

struct x {
  int i : 1;
  volatile int j : 1;
};

Where we clearly cannot access i without modifying j (but it's still
valid C).  So I don't think that a volatile member inside a non-volatile
struct guarantees anything.

Now, with

struct x {
    long a;
    volatile unsigned int lock;
    unsigned int full : 1;
};

void
wrong(volatile struct x *ptr)
{
  ptr->full = 1;
}

IA64 uses

        .mmi
        ld8.acq r14 = [r32]
        ;;
        nop 0
        dep r14 = r15, r14, 32, 1
        ;;
        .mib
        st8.rel [r32] = r14

which seems to be an attempt to work around this issue (albeit a
possibly very slow one).