This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets
- From: "glisse at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 13 Jun 2016 21:42:02 +0000
- Subject: [Bug middle-end/71488] [6/7 Regression] Wrong code for vector comparisons with ivybridge and westmere targets
- Auto-submitted: auto-generated
- References: <bug-71488-4 at http dot gcc dot gnu dot org/bugzilla/>
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 :-(