From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 97087394D825; Tue, 24 Mar 2020 21:34:54 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 97087394D825
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1585085694;
 bh=3WxyJLcjuhFSaGiFc8sk0ceccQZDam7yU9iDYL4Jcok=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=bu8dQonh7Z1FMBhqtae1q4MTWETK69Hc1dcUncL1zpqmSPTh06wnv9rgemCrQnP6H
 Wx46jvAFgAiGncb25c+gOda4OCFQGe9LNvhw27c6Uq2puHLNrudx2R3U4JnHWJ9tQS
 rrOPSfVM0dGRAiHaOUsBB7rr+XfeC0kEjr8OZ1wY=
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/94295] use __builtin_operator_new and
 __builtin_operator_delete when available
Date: Tue, 24 Mar 2020 21:34:54 +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: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
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-94295-4-Z4fcuFEnrc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-94295-4@http.gcc.gnu.org/bugzilla/>
References: <bug-94295-4@http.gcc.gnu.org/bugzilla/>
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-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <http://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2020 21:34:54 -0000

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

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Smith from comment #2)
> (In reply to Marc Glisse from comment #1)
> > (In reply to Richard Smith from comment #0)
> > > The C++ language rules do not permit optimization (eg, deletion) of d=
irect
> > > calls to 'operator new' and 'operator delete'.
> >=20
> > I thought that was considered a bug?
>=20
> No, it's intentional: if the user directly calls '::operator new(42)' and
> they've replaced that function, the replacement function is guaranteed to=
 be
> called. In this regard, 'operator new' is just a regular function with a
> funny name.
>=20
> To be clear, the implicit call to 'operator new' produced by, say, 'new i=
nt'
> *is* optimizable, but a direct explicit call to 'operator new(sizeof(int)=
)'
> is not.

Ah, since you are here, and you appeared as an author of N3664 but not N3537
(precisely when this subtlety happened), could you explain why? It isn't
discussed in the paper, complicates the design, and I cannot think of any u=
se
for this distinction (there are workarounds if people don't want their expl=
icit
call elided).

This of course doesn't at all prevent from adding a __builtin_operator_new
option in std::allocator, it only affects how motivated we should be to fix=
 the
non-conformance.=