[Bug c++/56126] New: -fno-exceptions produces constructors that rely on exceptions to signal errors in operator new

[Bug c++/56126] New: -fno-exceptions produces constructors that rely on exceptions to signal errors in operator new

[bruck.michael at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

             Bug #: 56126
           Summary: -fno-exceptions produces constructors that rely on
                    exceptions to signal errors in operator new
    Classification: Unclassified
           Product: gcc
           Version: 4.6.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bruck.michael@googlemail.com


Code generated with -fno-exceptions active does not check for nullptr on return
from operator new unless throw() is specified.

In code compiled with -fno-exceptions nothing can be thrown, consequently all
new operators should imply throw() or a warning/error should occur when new
operators without throw() are used.

$ cat test.cpp
#include <stdio.h>

void * operator new(size_t size) //throw()
{
    return 0;
}

struct foo
{
    virtual void dummy() {}
};

int main()
{
    foo * f = new foo();

    printf("f = %p\n", f);
}

$ gcc test.cpp -fno-exceptions -fno-rtti
test.cpp: In function ‘void* operator new(size_t)’:
test.cpp:5:12: warning: ‘operator new’ must not return NULL unless it is
declared ‘throw()’ (or -fcheck-new is in effect)

$ ./a.out
Segmentation fault (core dumped)


The compiler diagnostic only appears because this example is reduced and the
compiler can evaluate the return value at compile time. In real-life the
compiler will generate code that assumes that all new errors return as
exceptions even though exceptions are disabled.

The example crashes when the vtable pointer is written, likewise but not shown
here the compiler calls the constructor with this == nullptr.

[Bug c++/56126] -fno-exceptions produces constructors that rely on exceptions to signal errors in operator new

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-28 04:54:56 UTC ---
The warning says you could use -fcheck-new .

[Bug c++/56126] -fno-exceptions produces constructors that rely on exceptions to signal errors in operator new

[bruck.michael at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #2 from Michael Bruck <bruck.michael at googlemail dot com> 2013-01-28 05:12:57 UTC ---
(In reply to comment #1)
> The warning says you could use -fcheck-new .

Yes, but in normal code you never see the warning.

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[bruck.michael at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #3 from Michael Bruck <bruck.michael at googlemail dot com> 2013-01-28 05:25:43 UTC ---
(In reply to comment #1)
> The warning says you could use -fcheck-new .

Changed the title to account for this.

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[olafvdspek at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

Olaf van der Spek <olafvdspek at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olafvdspek at gmail dot com

--- Comment #4 from Olaf van der Spek <olafvdspek at gmail dot com> ---
Isn't abort() called when new fails with -fno-exceptions?

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[bruck.michael at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #5 from Michael Bruck <bruck.michael at googlemail dot com> ---
@Olaf

"5.3.4 New
13 [Note: unless an allocation function is declared with a non-throwing
exception-specification (15.4), it indicates failure to allocate storage by
throwing a std::bad_alloc exception (Clause 15, 18.6.2.1); it returns a
non-null pointer otherwise. If the allocation function is declared with a
non-throwing exception-specification, it returns null to indicate failure to
allocate storage and a non-null pointer otherwise. —end note] If the allocation
function returns null, initialization shall not be done, the deallocation
function shall not be called, and the value of the new-expression shall be
null."
>From gcc-bugs-return-472153-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jan 04 03:08:25 2015
Return-Path: <gcc-bugs-return-472153-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18648 invoked by alias); 4 Jan 2015 03:08:22 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17444 invoked by uid 48); 4 Jan 2015 03:07:58 -0000
From: "bdavis at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/63494] ICE with deferred-character-length component
Date: Sun, 04 Jan 2015 03:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bdavis at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-63494-4-YDWnhnF7Yr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63494-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63494-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg00147.txt.bz2
Content-length: 635

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc494

Bud Davis <bdavis at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bdavis at gcc dot gnu.org

--- Comment #3 from Bud Davis <bdavis at gcc dot gnu.org> ---
        type :: lrStringType
          character(:), allocatable :: a
        end type

        type(lrStringType), allocatable :: storage(:)
        storage(1)%a(j+2:) ='a'
        end


I think the above is a bit more concise representative of the problem.

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Using -fno-exceptions says "I do not want ISO C++" so quoting the standard
isn't very relevant.

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Why would you want an operator new that can't throw but is declared to
potentially throw? The exception specification is defined by the language to
inform the compiler whether to check the result or not, so use that.

IMHO if your operator new returns null instead of throwing then it should be
declared non-throwing (which can be done conditionally based on whether
exceptions are enabled).

If declaring it like that really isn't possible, then you should use
-fcheck-new, but it seems OK to not enable that automatically and rely on
correct exception specifications.

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[olafvdspek at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #8 from Olaf van der Spek <olafvdspek at gmail dot com> ---
(In reply to Michael Bruck from comment #0)
> In code compiled with -fno-exceptions nothing can be thrown, consequently
> all new operators should imply throw() or a warning/error should occur when
> new operators without throw() are used.

No, as you could (should?) abort/terminate instead of returning NULL.

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[bruck.michael at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #9 from Michael Bruck <bruck.michael at googlemail dot com> ---
> Jonathan: Using -fno-exceptions says "I do not want ISO C++" so quoting the standard isn't very relevant.
> Olaf: No, as you could (should?) abort/terminate instead of returning NULL.

I quoted it to illustrate that returning NULL is the intuitive option here,
while abort() is a completely new approach. Returning NULL is what I would
expect to be the case when -fno-exceptions is active and it is what happens in
the libc++ implementation AFAIK.

> Why would you want an operator new that can't throw but is declared to potentially throw?

Because -fno-exceptions suggests to the user that they can produce safe code
without using any exception-specific C++ syntax. 

https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html
"The last language feature needing to be transformed by -fno-exceptions is
treatment of exception specifications on member functions. Fortunately, the
compiler deals with this by ignoring exception specifications and so no
alternate source markup is needed."

If the authors of the libstdc++ docs get this wrong, how is the average
compiler user expected to know this?

Likewise GCC's documentation also pretends this case doesn't exist:

https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/C_002b_002b-Dialect-Options.html
"-fcheck-new
Check that the pointer returned by operator new is non-null before attempting
to modify the storage allocated. This check is normally unnecessary because the
C++ standard specifies that operator new only returns 0 if it is declared
‘throw()’, in which case the compiler always checks the return value even
without this option. In all other cases, when operator new has a non-empty
exception specification, memory exhaustion is signalled by throwing
std::bad_alloc. See also ‘new (nothrow)’. "

> The exception specification is defined by the language to inform the compiler whether to check the result or not, so use that.
> If declaring it like that really isn't possible, then you should use -fcheck-new, but it seems OK to not enable that automatically and rely on correct exception specifications.

As you pointed out we are outside the standard with -fno-exceptions. There is
certainly no rule that prevents the compiler from issuing a warning when it
generates code that is highly unlikely to be safe.
>From gcc-bugs-return-472304-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 06 13:37:24 2015
Return-Path: <gcc-bugs-return-472304-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26175 invoked by alias); 6 Jan 2015 13:37:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 26152 invoked by uid 48); 6 Jan 2015 13:37:20 -0000
From: "chrbr at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64507] SH inlined builtin strncmp doesn't return 0 for 0 length
Date: Tue, 06 Jan 2015 13:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: chrbr at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-64507-4-fOStPF8FRe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64507-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64507-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg00298.txt.bz2
Content-length: 406

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd507

chrbr at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from chrbr at gcc dot gnu.org ---
fixed in 4.9 qnd trunk

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[olafvdspek at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #10 from Olaf van der Spek <olafvdspek at gmail dot com> ---
On Tue, Jan 6, 2015 at 2:22 PM, bruck.michael at googlemail dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126
>
> --- Comment #9 from Michael Bruck <bruck.michael at googlemail dot com> ---
>> Jonathan: Using -fno-exceptions says "I do not want ISO C++" so quoting the standard isn't very relevant.
>> Olaf: No, as you could (should?) abort/terminate instead of returning NULL.
>
> I quoted it to illustrate that returning NULL is the intuitive option here,
> while abort() is a completely new approach. Returning NULL is what I would
> expect to be the case when -fno-exceptions is active and it is what happens in
> the libc++ implementation AFAIK.

-fno-exceptions transforms throws into aborts in the STL.
Unfortunately it doesn't do that for other code but I've filed a
feature request for to fix that.

Given this transformation aborting would be the natural consequence.
What does the GCC STL do?

>> Why would you want an operator new that can't throw but is declared to potentially throw?
>
> Because -fno-exceptions suggests to the user that they can produce safe code
> without using any exception-specific C++ syntax.

I think we disagree on that part.

BTW, what's your use case? Do you really want to check NULL on every
call to new?

Olaf

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[bruck.michael at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #11 from Michael Bruck <bruck.michael at googlemail dot com> ---
(In reply to Olaf van der Spek from comment #10)
> > I quoted it to illustrate that returning NULL is the intuitive option here,
> > while abort() is a completely new approach. Returning NULL is what I would
> > expect to be the case when -fno-exceptions is active and it is what happens in
> > the libc++ implementation AFAIK.
> 
> -fno-exceptions transforms throws into aborts in the STL.
> Unfortunately it doesn't do that for other code but I've filed a
> feature request for to fix that.
> 
> Given this transformation aborting would be the natural consequence.
> What does the GCC STL do?

throwing is undefined behavior with -fno-exceptions. Allocation failure is a
simple error and should not kill your program.

> BTW, what's your use case? Do you really want to check NULL on every
> call to new?

With -fno-exceptions you have to check all functions for errors, including
allocation.

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[olafvdspek at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #12 from Olaf van der Spek <olafvdspek at gmail dot com> ---
On Thu, Jan 8, 2015 at 10:20 PM, bruck.michael at googlemail dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
> throwing is undefined behavior with -fno-exceptions.

Says who?

> Allocation failure is a
> simple error and should not kill your program.

It's far from simple to handle properly and to do better then abort.

>> BTW, what's your use case? Do you really want to check NULL on every
>> call to new?
>
> With -fno-exceptions you have to check all functions for errors, including
> allocation.

What's your use case?

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Michael Bruck from comment #11)
> throwing is undefined behavior with -fno-exceptions.

No it isn't, it's ill-formed due to a syntax error. That's very different to
undefined behaviour.

[Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw()

[bruck.michael at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56126

--- Comment #15 from Michael Bruck <bruck.michael at googlemail dot com> ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Michael Bruck from comment #11)
> > throwing is undefined behavior with -fno-exceptions.
> 
> No it isn't, it's ill-formed due to a syntax error. That's very different to
> undefined behaviour.

I misunderstood Olaf, I guess he means they replace them via preprocessor
macros. In any case it is different from an allocation failure, which was my
point.