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.

Reply via email to