This is the mail archive of the
mailing list for the GCC project.
Re: operator new returns nonzero
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Basile Starynkevitch <basile at starynkevitch dot net>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 7 Sep 2013 13:52:52 +0200 (CEST)
- Subject: Re: operator new returns nonzero
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1309071206340 dot 19326 at stedding dot saclay dot inria dot fr> <1378554262 dot 8706 dot 26 dot camel at glinka dot lesours>
On Sat, 7 Sep 2013, Basile Starynkevitch wrote:
On Sat, 2013-09-07 at 12:33 +0200, Marc Glisse wrote:
this patch teaches the compiler that operator new, when it can throw,
isn't allowed to return a null pointer. Note that it doesn't work for
placement new (that one may have to be handled in the front-end or the
inliner), and it will not work on user-defined operator new if they are
inlined. I guess it would be possible to teach the inliner to insert an
assert_expr or something when inlining such a function, but that's not for
now. The code I removed from vrp_visit_stmt was duplicated in
stmt_interesting_for_vrp and thus useless.
Interesting patch. However, I feel that we should give advanced users
the ability to say that their new operator is never returning null...
Easy, don't specify noexcept on it and that's what the patch already does,
as long as the function is not inlined.
In particular, if I define my own new operator which never returns nil,
I find strange that it would be less optimized than the system's
Perhaps we need an attribute `nonnullresult' which whould means that.
(we already the nonnull attribute for function arguments)
There is already a PR about that, linked from this PR. But even if we
create this attribute, we will still want to be able to guess that new
should have it even if it isn't written.