https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483
Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2014-05-28 00:00:00         |2019-6-27
                 CC|                            |rguenth at gcc dot gnu.org
      Known to fail|                            |9.1.0

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Wit GCC 9 and trunk we are left with

  <bb 2> [local count: 118111600]:
  MEM[(int *)&D.30957] = 85899345930;
  D.30957[2] = 30;
  _33 = operator new (12);
  __builtin_memcpy (_33, &D.30957, 12);
  _41 = MEM[(const int &)_33];
  __init_42 = _41 + 100;
  _50 = MEM[(const int &)_33 + 4];
  __init_19 = __init_42 + _50;
  _14 = MEM[(const int &)_33 + 8];
  __init_16 = _14 + __init_19;
  operator delete (_33);
  D.30957 ={v} {CLOBBER};
  return __init_16;

here I think operator new clobbers D.30957 which escapes at the memcpy call.
This prevents a late FRE from doing its job (not sure if a late one is
really needed).

Reply via email to