[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency

["torvald at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #12 from torvald at gcc dot gnu.org ---
(In reply to algrant from comment #11)
> Where do you get that this is racy if the access to data is not atomic?

In threadB(), you do:

      f = flag.load(std::memory_order_consume);             // B.A
      d = *(&data + f - f);                                 // B.B

That reads from data irrespective of the value of f, so will read when data is
actually not "owned" by threadB.  You can either make the accesses to data
atomic, or move the load from data to after checking that flag equals 1.

> By
> design, release/acquire and release/consume sequences don't require
> wholesale changes to the way the data payload (in the general case, multiple
> fields within a structure) is first constructed and then used.  1.10#13
> makes clear that as a result of the intra-thread sequencing between atomic
> and non-atomic operations (1.9#14), and the inter-thread ordering between
> atomic operations (1.10 various), there is a resulting ordering on
> operations to "ordinary" (sic) objects.  Please see the references to the
> C++ standard in the source example, for the chain of reasoning here.

I'm very much aware of the rules, I believe.  But as far as you can see,
there's a data race in your test program, which results in undefined behavior.