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

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

[glisse at gcc dot gnu.org]

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

            Bug ID: 59894
           Summary: Force use of the default new/delete
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org

Hello,

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.

I wonder if we could provide a flag in libstdc++ so that if the user compiles
his code with -D_GLIBCXX_FORCE_DEFAULT_ALLOCATION (a better name would be
welcome), <new> defines inline versions of the operators. We might even want to
skip new_handler in that version, I am not sure.

I didn't think too long about the possible drawbacks, but defining the macro
would be a pretty clear message from the user that he takes full responsibility
for all the consequences.

(we are also using, in the same code, extern "C" __typeof(malloc) malloc
__attribute__((returns_nonnull)); so it really simplifies, but PR 59875 shows
that simplifying operator delete(0) would already be nice)

PR 59893 considers a different path using LTO to inline at link time the
definition from libsupc++.

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

[trippels at gcc dot 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.

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

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #1)
> Isn't inlining forbidden by the standard?

Yes (sorry, I mentioned that in PR 59875 and forgot to repeat it here), but
since this is a specific option where the user explicitly asks for the
non-standard behavior...

Besides, the rationale in issue 404 seems bogus, I can use an inline
replacement memory allocation function just fine with gcc, and it has value to
several users.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-21
     Ever confirmed|0                           |1

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think this is a reasonable (non-standard) option to want. There are
definitely users who don't replace the global new/delete functions but would
appreciate the extra inlining opportunities.

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

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #0)
> PR 59893 considers a different path using LTO to inline at link time the
> definition from libsupc++.

Note that doing both at the same time:
1) provide an inline version of new
2) LTO-link with libsupc++
might interact badly (or not, I haven't checked). We should test it and if
needed warn about it in the documentation or preferably find a workaround.