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)
