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 B5EC63858C5E; Wed,  2 Aug 2023 04:20:07 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B5EC63858C5E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1690950007;
	bh=h1Q3RcW6lQHZQd5ORjUfB9JHuFZWwiT06vfKa2xq1Oo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ICklm9xZyDDG15y2gG8gY94epZybov3aHgWVMBLvygYrzSKHnCn/IV/6yGoQ/cZtr
	 3hUnZ8QY7pqVpqM5g4SyKwGcb8aRJAm5JexrpAxv8xaTY68rvm8pO+4F4SVEdrEurf
	 nSlhb8IAET2BSNrHI8d9H+9597sv359ssZ+qnzWs=
From: "hiraditya at msn dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/110137] implement clang -fassume-sane-operator-new
Date: Wed, 02 Aug 2023 04:20:07 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: hiraditya at msn dot com
X-Bugzilla-Status: NEW
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-110137-4-4oho7Qi36N@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110137-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110137-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #3 from AK <hiraditya at msn dot com> ---
1. clang also has noalias on nothrow versions of operator new. will
`-fassume-sane-operator-new` enable that as well?

2. as per: http://eel.is/c++draft/basic.stc.dynamic#allocation-2=20

"""If the request succeeds, the value returned by a replaceable allocation
function is a non-null pointer value ([basic.compound]) p0 different from a=
ny
previously returned value p1, unless that value p1 was subsequently passed =
to a
replaceable deallocation function."""

Does this mean that all successful new allocations can be assumed to be a
noalias as long as the pointer wasn't passed to a deallocation function? In
that case when possible, can the compiler `infer` from a bottom-up analysis
that an allocation is a noalias?=