From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D25C73853556; Mon, 5 Jun 2023 11:13:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D25C73853556 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685963615; bh=EqkiEDcSt6LB4OzDEBGtooafwRyZE7hHJoTjGYvyc88=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JwD9K9folqMkwiVPM6UHj73FKaB94Nv1fFj2xEEXQT0/8YtTmns/vBcyBDhpPcCVp 9oy6xxS6BaYnD+Lmb4X0/FBL7NP7rvWNaxYODcePP9ikahdN5PdwJ8AqdALTdERqYw ahEn1urWCV8/KGXZ9ph/+cv/tyApSWReu30UyiAA= From: "davmac at davmac dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/109967] [10/11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu Date: Mon, 05 Jun 2023 11:13:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: davmac at davmac dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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=3D109967 Davin McCall changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |davmac at davmac dot org --- Comment #3 from Davin McCall --- -fdisable-tree-cunroll avoids it. This is the take of someone who is new to poking GCC internals, so take this with a grain of salt, but: It looks like cunroll duplicates (partially unrolls, I suppose) the inner l= oop, meaning that `g' is live in two disjoint ranges, with a CLOBBER between the= m. Then later passes (fre5, but disabling it doesn't seem to help) recognise t= hat &g and &g are the same in both ranges and so use a single temporary for bot= h. This confuses cfgexpand (as Andrew Pinski notes) because the memory derefer= ence of the temporary isn't seen as an access of g (in add_scope_conflicts()/add_scope_conflicts_1()/visit_conflict()).=20 I don't understand the IR semantics well enough to know the right fix - per= haps cunroll should be removing the clobber (does a clobber affect storage lifet= ime or only value?), or perhaps cfgexpand should be more conservative when it s= ees a memory access.=