https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-09-16
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
That's simply because the middle-end (alias analysis) doesn't know anything
about
the atomic builtins.
Which is because to me it's not exactly clear as for what other operations an
atomic load/store is a barrier for. [and for the middle-end "barrier" means
possibly clobbering/using]
Note that we expand the loads/stores to MEMs using ALIAS_SET_MEMORY_BARRIER
which means it conflicts with any other load/store on RTL (which matches
the behavior seen on GIMPLE).
In addition to that on GIMPLE the ATOMIC builtins make the input pointers
escape (that's surely not required), but they are usually globals anyway.
;; _52 = __atomic_load_4 (&MEM[(const struct __atomic_base *)&std_x]._M_i, 0);
(insn 25 24 0 (set (reg:SI 112 [ D.37281 ])
(mem/v:SI (symbol_ref:DI ("std_x") [flags 0x2] <var_decl
0x7ffff4c5ad10 std_x>) [-1 S4 A32]))
/usr/include/c++/4.9/bits/atomic_base.h:500 -1
(nil))
Confirmed. But eventually that's by design to make locking primitives work
(where we may not move any loads/stores into/out of the protected region).
