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 10761385E008; Tue, 24 Mar 2020 20:26:29 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 10761385E008
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1585081589;
 bh=6UxIVCTsRem516LhtLxbXJPND8RtH7CpO302H6LIec4=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=FBoNhHly+FpSL+zj/sa8X0UKrOevGmNyij2wVezFEtzeox6gq/Dne4Pba90bZt8Hl
 6EwchvxaeM0IZtzD8NNcZ3F+gRX5tBhxCAoR5G19BUMOQCa7gvNFk/tijgIvPuoaLf
 AiESnoY7UZTnaZke/42DCe81Tn50EEj/ldPLm+m4=
From: "richard-gccbugzilla at metafoo dot co.uk" <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 20:26:28 +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: richard-gccbugzilla at metafoo dot co.uk
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-5YJciSOX0f@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 20:26:29 -0000

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

--- Comment #2 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk=
> ---
(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 dir=
ect
> > calls to 'operator new' and 'operator delete'.
>=20
> I thought that was considered a bug?

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 fu=
nny
name.

To be clear, the implicit call to 'operator new' produced by, say, 'new int'
*is* optimizable, but a direct explicit call to 'operator new(sizeof(int))'=
 is
not.

> Gcc does optimize those, like it does malloc/free...

That sounds like non-conforming behavior.

> > This bug requests that libstdc++ uses these builtins when available.
>=20
> So just in std::allocator, or are there other places?

std::allocator's specification has an explicit provision to permit these
optimizations, see [allocator.members]/4:

"The storage for the array is obtained by calling ::operator new (17.6.2), =
but
it is unspecified when or how often this function is called."

In Clang + libc++ at least, we interpret that as meaning we can call
'::operator new' zero times if we don't need the storage, just like for a
new-expression, and the LWG members I've talked to about this have agreed t=
hat
that's in line with the intent.=