This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Sat, 7 Sep 2013, Mike Stump wrote:
On Sep 7, 2013, at 3:33 AM, Marc Glisse <marc.glisse@inria.fr> wrote:this patch teaches the compiler that operator new, when it can throw, isn't allowed to return a null pointer.You sure: @item -fcheck-new @opindex fcheck-new Check that the pointer returned by @code{operator new} is non-null before attempting to modify the storage allocated. This check is normally unnecessary because the C++ standard specifies that @code{operator new} only returns @code{0} if it is declared @samp{throw()}, in which case the compiler always checks the return value even without this option. In all other cases, when @code{operator new} has a non-empty exception specification, memory exhaustion is signalled by throwing @code{std::bad_alloc}. See also @samp{new (nothrow)}. ?
Thanks, I didn't know that option. But it doesn't do the same. -fcheck-new is about the front-end inserting a test !=0 between malloc and the constructor. My patch is about teaching the middle-end that the value is not zero (so even user-coded comparisons with 0 can be simplified).
Now flag_check_new should probably disable this optimization... The 3 -fcheck-new testcases in the testsuite probably only pass because they don't have -O2.
-- Marc Glisse
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |