[Bug libstdc++/59894] Force use of the default new/delete

["trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(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 functions
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 <new> (3.7.4, 18.6):
— operator new(std::size_t)
— operator new(std::size_t, const std::nothrow_t&)
— operator new[](std::size_t)
— operator new[](std::size_t, const std::nothrow_t&)
— operator delete(void*)
— operator delete(void*, const std::nothrow_t&)
— operator delete[](void*)
— operator delete[](void*, const std::nothrow_t&)
The program’s 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’s
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: <gcc-bugs-return-441068-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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 23258 invoked by uid 48); 20 Jan 2014 21:57:21 -0000
From: "patrick at motec dot com.au" <gcc-bugzilla@gcc.gnu.org>
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: <bug-55113-4-94x8913Xd9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55113-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55113-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: 2014-01/txt/msg02210.txt.bz2
Content-length: 541

http://gcc.gnu.org/bugzilla/show_bug.cgi?idU113

--- Comment #12 from Patrick Oppenlander <patrick at motec dot com.au> ---
(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.