[Bug rtl-optimization/78778] non-atomic load moved to before atomic load with std::memory_order_acquire
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Dec 13 10:39:00 GMT 2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78778
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-12-13
Ever confirmed|0 |1
Known to fail| |6.2.1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I don't think this is a speculative load. GIMPLE with more details:
<bb 2>:
pretmp_14 = &MEM[(const struct __atomic_base *)seq_3(D)]._M_i;
<bb 3>:
# .MEM_1 = PHI <.MEM_13(3), .MEM_2(D)(2), .MEM_13(4)>
# .MEM_12 = VDEF <.MEM_1>
_11 = __atomic_load_8 (pretmp_14, 2);
# VUSE <.MEM_12>
copy_5 = *value_4(D);
# .MEM_13 = VDEF <.MEM_12>
_9 = __atomic_load_8 (pretmp_14, 2);
if (_9 == _11)
goto <bb 4>;
else
goto <bb 3>;
<bb 4>:
_6 = _9 & 1;
if (_6 == 0)
goto <bb 5>;
else
goto <bb 3>;
<bb 5>:
_7 = (int) copy_5;
# VUSE <.MEM_13>
return _7;
this shows that the atomic loads have memory side-effects (they have a VDEF).
It appears that on RTL this critical piece is missing as we simply expand to
;; Generating RTL for gimple basic block 3
;; _11 = __atomic_load_8 (pretmp_14, 2);
(insn 9 8 0 (set (reg:DI 90 [ _11 ])
(mem/v:DI (reg/f:DI 91 [ pretmp_14 ]) [-1 S8 A64]))
/usr/include/c++/6/bits/atomic_base.h:396 -1
(nil))
;; copy_5 = *value_4(D);
(insn 10 9 0 (set (reg/v:DF 87 [ copy ])
(mem:DF (reg/v/f:DI 94 [ value ]) [2 *value_4(D)+0 S8 A64])) t.c:9 -1
(nil))
;; _9 = __atomic_load_8 (pretmp_14, 2);
(insn 11 10 0 (set (reg:DI 89 [ _9 ])
(mem/v:DI (reg/f:DI 91 [ pretmp_14 ]) [-1 S8 A64]))
/usr/include/c++/6/bits/atomic_base.h:396 -1
(nil))
so any notion of "atomicity" is lost (it looks like the MEM is volatile
though?)
Confirmed.
More information about the Gcc-bugs
mailing list