https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71488
--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
Independently of the wrong code issue, we are generating pretty bad code on
Uros' testcase. It is full of operator delete(0) and operator new(0). The first
one we could drop, but the second one is forced by the C++ standard to allocate
at least one byte (or throw). It probably comes from the copy constructor of
valarray. And even when I help with the usual:
__attribute__((returns_nonnull)) __typeof__(malloc) malloc;
inline void* operator new(std::size_t n){return malloc(n);}
inline void operator delete(void*p)noexcept{free(p);}
the .optimized dump still has things like
MEM[(struct valarray *)_61]._M_data = _45;
_46 = MEM[(struct valarray *)_61]._M_data;
because of how late other optimizations happened. Quite a common occurrence
with C++ code :-(
