From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19070 invoked by alias); 6 Jan 2015 13:22:46 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 19036 invoked by uid 48); 6 Jan 2015 13:22:39 -0000 From: "bruck.michael at googlemail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/56126] -fno-exceptions should activate -fcheck-new or issue diagnostic for all new operators without throw() Date: Tue, 06 Jan 2015 13:22:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.6.3 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bruck.michael at googlemail dot com X-Bugzilla-Status: UNCONFIRMED 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: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg00297.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D56126 --- Comment #9 from Michael Bruck --- > Jonathan: Using -fno-exceptions says "I do not want ISO C++" so quoting t= he standard isn't very relevant. > Olaf: No, as you could (should?) abort/terminate instead of returning NUL= L. 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 po= tentially throw? Because -fno-exceptions suggests to the user that they can produce safe code without using any exception-specific C++ syntax.=20 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.ht= ml "-fcheck-new Check that the pointer returned by operator new is non-null before attempti= ng 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 =E2=80=98throw()=E2=80=99, in which case the compiler always checks the ret= urn 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 =E2=80=98new (nothrow)=E2=80=99. " > The exception specification is defined by the language to inform the comp= iler whether to check the result or not, so use that. > If declaring it like that really isn't possible, then you should use -fch= eck-new, but it seems OK to not enable that automatically and rely on corre= ct 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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?id=64507 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