http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875
Bug ID: 59875
Summary: Weak symbols in glibc prevent optimizations
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: josephlawrie at hotmail dot com
The following (weird) code changed from a stackoverflow post demonstrates the
problem:
#include <array>
#include <cassert>
#include <cstdlib>
/*
void * operator new(std::size_t n) throw(std::bad_alloc)
{
return malloc(n);
}
void operator delete(void * p) throw()
{
if(p != nullptr)
free(p);
}
/*
class P {
public:
P() : _value(nullptr) {}
~P() { delete _value; }
private:
char *_value;
};
void foo() {
if(std::array<P, 4>().size() != 4)
assert(false);
}
(compiled with g++ -std=c++11 -O3 -fno-weak -static -Wa,-alh test.cpp -o test)
The result of delete _value cannot be eliminated (and hence neither can array
construction, etc) even though the standard says something to the effect of
"The value of the first argument supplied to a deallocation function may be a
null pointer value; if so, and if the deallocation function is one supplied in
the standard library, the call has no effect." i.e, delete should do nothing.
I thought this has something to do with the fallback to glibc's free which can
be hooked (and hence the delete's side effect are unknown). The uncommented
version however still contains a call to free, so it is possibly just a
constant propagation thing.
