public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/35878] Useless NULL pointer check when constructing object
[not found] <bug-35878-4@http.gcc.gnu.org/bugzilla/>
@ 2013-09-11 12:59 ` glisse at gcc dot gnu.org
2013-09-11 13:39 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: glisse at gcc dot gnu.org @ 2013-09-11 12:59 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug c++/35878] Useless NULL pointer check when constructing object
[not found] <bug-35878-4@http.gcc.gnu.org/bugzilla/>
2013-09-11 12:59 ` [Bug c++/35878] Useless NULL pointer check when constructing object glisse at gcc dot gnu.org
@ 2013-09-11 13:39 ` redi at gcc dot gnu.org
2013-09-11 16:58 ` [Bug libstdc++/35878] " glisse at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2013-09-11 13:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #2)
> 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.
Yes, I'm inclined to agree.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/35878] Useless NULL pointer check when constructing object
[not found] <bug-35878-4@http.gcc.gnu.org/bugzilla/>
2013-09-11 12:59 ` [Bug c++/35878] Useless NULL pointer check when constructing object glisse at gcc dot gnu.org
2013-09-11 13:39 ` redi at gcc dot gnu.org
@ 2013-09-11 16:58 ` glisse at gcc dot gnu.org
2013-09-11 19:08 ` redi at gcc dot gnu.org
2014-11-29 19:40 ` [Bug libstdc++/35878] [LWG 2302] " glisse at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: glisse at gcc dot gnu.org @ 2013-09-11 16:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878
Marc Glisse <glisse at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-09-11
Component|c++ |libstdc++
Ever confirmed|0 |1
--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
Confirming then. Jonathan, you didn't send a mail to the reflectors after your
post on SO, did you? Unless you want to do it, I think I'll send one, just to
make sure there is no hope of removing that check at the core level.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/35878] Useless NULL pointer check when constructing object
[not found] <bug-35878-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2013-09-11 16:58 ` [Bug libstdc++/35878] " glisse at gcc dot gnu.org
@ 2013-09-11 19:08 ` redi at gcc dot gnu.org
2014-11-29 19:40 ` [Bug libstdc++/35878] [LWG 2302] " glisse at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2013-09-11 19:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
No, I never got round to sending it to the reflector, but I'd be interested to
hear the committee's views on a change.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug libstdc++/35878] [LWG 2302] Useless NULL pointer check when constructing object
[not found] <bug-35878-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2013-09-11 19:08 ` redi at gcc dot gnu.org
@ 2014-11-29 19:40 ` glisse at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-11-29 19:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878
--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
LWG marked issue 2302 as pending NAD, but CWG was more helpful and we now have
an official DR so we can patch the front-end:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1748
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/35878] New: Useless NULL pointer check when constructing object
@ 2008-04-08 21:37 ian at airs dot com
2008-04-08 21:41 ` [Bug c++/35878] " pinskia at gcc dot gnu dot org
0 siblings, 1 reply; 6+ messages in thread
From: ian at airs dot com @ 2008-04-08 21:37 UTC (permalink / raw)
To: gcc-bugs
Consider this trivial C++ test case:
#include <vector>
void foo(std::vector<int>* v, int i) { v->push_back(i); }
When I compile this with current trunk with -O2 on i686-pc-linux-gnu I see,
among other things, this:
movl 4(%edi), %edx
cmpl 8(%edi), %edx
je .L2
testl %edx, %edx
je .L3
movl -4(%edx), %eax
movl %eax, (%edx)
movl 4(%edi), %edx
.L3:
leal 4(%edx), %eax
movl %eax, 4(%edi)
Note that test for whether %edx is NULL. That comes from this in the
.004t.gimple file:
D.7266 = operator new (4, D.7265);
D.7264 = (int *) D.7266;
if (D.7264 != 0B)
{
try
{
D.7268 = *__val;
*D.7264 = D.7268;
}
catch
{
operator delete (D.7264, D.7265);
}
iftmp.48 = D.7264;
}
else
{
iftmp.48 = D.7264;
}
We get rid of the try/catch pretty quickly, but we never manage to get rid of
the NULL pointer check.
I believe the NULL pointer check is being generated by build_new_1 in cp/init.c
because we are using a type for which TYPE_NOTHROW_P is true.
This NULL pointer check serves no useful purpose. It is essentially an
abtraction penalty. We should figure out some way to get rid of it, either in
the C++ frontend, or in some later optimization pass.
--
Summary: Useless NULL pointer check when constructing object
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-11-29 19:40 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-35878-4@http.gcc.gnu.org/bugzilla/>
2013-09-11 12:59 ` [Bug c++/35878] Useless NULL pointer check when constructing object glisse at gcc dot gnu.org
2013-09-11 13:39 ` redi at gcc dot gnu.org
2013-09-11 16:58 ` [Bug libstdc++/35878] " glisse at gcc dot gnu.org
2013-09-11 19:08 ` redi at gcc dot gnu.org
2014-11-29 19:40 ` [Bug libstdc++/35878] [LWG 2302] " glisse at gcc dot gnu.org
2008-04-08 21:37 [Bug c++/35878] New: " ian at airs dot com
2008-04-08 21:41 ` [Bug c++/35878] " pinskia at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).