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).