From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22888 invoked by alias); 20 Jan 2014 21:57:17 -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 22112 invoked by uid 48); 20 Jan 2014 21:57:10 -0000 From: "trippels at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/59894] Force use of the default new/delete Date: Mon, 20 Jan 2014 21:57:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: trippels at gcc dot gnu.org 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: cc 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: 2014-01/txt/msg02209.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59894 Markus Trippelsdorf changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- (In reply to Marc Glisse from comment #0) > operator new and operator delete are hidden in libsupc++ so they can be > easily replaced, either directly in the code, or later by interposing a > library. Doing so has a cost, and I have seen people (and done it myself) > providing a definition in their code that was roughly equivalent to the > standard one, just so it could be inlined. Isn't inlining forbidden by the standard? (see also http://cplusplus.github.io/LWG/lwg-defects.html#404) quote: 17.6.4.6 Replacement functions [replacement.functions] Clauses 18 through 30 and Annex D describe the behavior of numerous functi= ons defined by the C ++ standard library. Under some circumstances, however, certain of these function descriptions also apply to replacement functions defined in the program (17.3). A C ++ program may provide the definition for any of eight dynamic memory allocation function signatures declared in header (3.7.4, 18.6): =E2=80=94 operator new(std::size_t) =E2=80=94 operator new(std::size_t, const std::nothrow_t&) =E2=80=94 operator new[](std::size_t) =E2=80=94 operator new[](std::size_t, const std::nothrow_t&) =E2=80=94 operator delete(void*) =E2=80=94 operator delete(void*, const std::nothrow_t&) =E2=80=94 operator delete[](void*) =E2=80=94 operator delete[](void*, const std::nothrow_t&) The program=E2=80=99s definitions are used instead of the default versions = supplied by the implementation (18.6). Such replacement occurs prior to program startup (3.2, 3.6). The program=E2= =80=99s definitions shall not be specified as inline. No diagnostic is required. >>From gcc-bugs-return-441068-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 20 21:57:25 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 23575 invoked by alias); 20 Jan 2014 21:57:25 -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 23258 invoked by uid 48); 20 Jan 2014 21:57:21 -0000 From: "patrick at motec dot com.au" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/55113] ICE with LTO and -fshort-double Date: Mon, 20 Jan 2014 21:57:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: patrick at motec dot com.au 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: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg02210.txt.bz2 Content-length: 541 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113 --- Comment #12 from Patrick Oppenlander --- (In reply to Andrew Pinski from comment #10) > -fshort-double is what is causing the issue. Why are you using that option > in the first place? It changes the ABI. We are using the option as it suits our e200z6 core very well. When it is in use GCC 4.4.3 generates efficient code using the scalar SPFP APU (efs* mnemonics). We don't have a hardware double-precision FPU, and no need for double precision math.