http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878
Marc Glisse <glisse at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED CC| |glisse at gcc dot gnu.org, | |redi at gcc dot gnu.org Resolution|DUPLICATE |--- --- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> --- I am separating this PR from PR 19476 because it really isn't the same at all. Copying Ian's later comment so it isn't lost: "Note that bug 35878, which was closed as a duplicate of this one, was a case of placement new. For placement new the check for a NULL pointer is particularly useless, as the language standard says that placement new is required to return the pointer which was passed in." The check for a null pointer after a call to placement new is sadly required by the standard (if anyone cares to try and get that changed, please go ahead). See this link for instance for an analysis: http://stackoverflow.com/questions/17571103/passing-null-pointer-to-placement-new p=new(nullptr)int(42); is an absurd but valid way of saying p=0;. For the compiler to know that the pointer is non-zero, it would need to see where the pointer is coming from, which is not the case in this testcase. The only place I can think of where we could tell the compiler to skip this check is in the library. I don't know if we should add if(p==0)__builtin_unreachable(); somewhere, or create a new attribute((neverzero)) for the pointer in the vector, or something else, but the knowledge that the pointer is not zero belongs in the library. (leaving as unconfirmed and not setting the component to libstdc++ because I'd like someone else to confirm this)