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.