From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A232D3858C5E; Thu, 12 Oct 2023 08:15:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A232D3858C5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1697098538; bh=K4Zxjb7BMs5kMqr4l353IGHjv1XLXH7mJy2v+DsAo9M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BKVFUowAnUBV4WLcNkqpNP3sOufsaSze/3CXbVLTIhQh1I0CWyRQhFV9hHy+jZlZX Uiyc9HFWFhkobBkT6v0McIbxUT45XkGQxO7Jscjfk/ZS+JPJoycF5YbPKP+HklO3MO fTAEL4T62hGc3Cg1YvtwKMewwicuIBIId61pl3BA= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/111773] Inconsistent optimization of replaced operator new() Date: Thu, 12 Oct 2023 08:15:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 13.2.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED 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: cf_reconfirmed_on bug_status component everconfirmed cc keywords Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111773 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2023-10-12 Status|UNCONFIRMED |ASSIGNED Component|c++ |ipa Ever confirmed|0 |1 CC| |hubicka at gcc dot gnu.org, | |marxin at gcc dot gnu.org, | |rguenth at gcc dot gnu.org Keywords| |wrong-code --- Comment #2 from Richard Biener --- For the second case I think we do something wrong. local-pure-const figures operator new is 'noreturn': Function is locally looping. Function is locally throwing. Function is locally malloc. Function found to be noreturn: operator new and fixup_cfg in turn turns main into int main () { int * D.3130; int * p1; int * _3(D); : operator new (4); } which would be fine I think. But then CDDCE decides Eliminating unnecessary statements: Deleting : operator new (4); and we end up with int main () { int * D.3130; int * p1; int * _3(D); : } and local-pure-const adds an unreachable: local analysis of int main()/18 checking previously known:Function is locally const. Function found to be noreturn: main Function found to be const: int main()/18 Declaration updated to be const: int main()/18 Function found to be nothrow: main Introduced new external node (void __builtin_unreachable()/32). int main () { int * D.3130; int * p1; int * _3(D); [count: 0]: __builtin_unreachable (); I think CD-DCE shouldn't remove the call as it's looping and noreturn. It doesn't mark the allocation as necessary because of -fallocation-dce: if (callee !=3D NULL_TREE && flag_allocation_dce && DECL_IS_REPLACEABLE_OPERATOR_NEW_P (callee)) return; we fail to check gimple_call_from_new_or_delete here I think (we later do it in most other places). But we maybe should never remove a control stmt which a noreturn call is, even more so as it can throw (yeah, we remove "dead" exceptions, but together with noreturn this doesn't quite match). Adding gimple_call_from_new_or_delete () will fix the testcase at hand but I think the same issue would exist with a class scope operator new triggered by a new expression. So, it's maybe not wrong we remove the call to ::operator new(), but if we do we have to preserve the 'return 10;' - we cannot do both, take advantage of 'noreturn' _and_ elide it. The behavior for the other testcase is OK I think.=