From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3C4A53857C59; Fri, 1 Oct 2021 06:18:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3C4A53857C59 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94 Date: Fri, 01 Oct 2021 06:18:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de 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: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 06:18:24 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102542 --- Comment #4 from rguenther at suse dot de --- On Thu, 30 Sep 2021, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102542 >=20 > Aldy Hernandez changed: >=20 > What |Removed |Added > -------------------------------------------------------------------------= --- > CC| |rguenth at gcc dot gnu.o= rg >=20 > --- Comment #2 from Aldy Hernandez --- > A little -fdbg-cnt bisecting magic shows that the first jump thread cause= s some > sort of reaction downstream in unrolljam: >=20 > ./cc1 a.c -quiet -O3 -fno-tree-ch -fdbg-cnt=3Dregistered_jump_thread:1-1 > ***dbgcnt: lower limit 1 reached for registered_jump_thread.*** > ***dbgcnt: upper limit 1 reached for registered_jump_thread.*** > during GIMPLE pass: unrolljam > a.c: In function =E2=80=98b=E2=80=99: > a.c:5:6: internal compiler error: Segmentation fault >=20 > So it's the first threading path that is causing an issue. Setting a > breakpoint at path registering yields this: >=20 > Breakpoint 5, jt_path_registry::register_jump_thread (this=3D0x391f150, P= ython > Exception There is no member or method named m_vecpfx= .:=20 > path=3D0x3a09430) > at /home/aldyh/src/gcc/gcc/tree-ssa-threadupdate.c:2838 > (gdb) p ::debug(path) > [1] Registering jump thread: (8, 4) incoming edge; (4, 3) normal;=20 >=20 > It's threading 8->4->3, which looks perfectly reasonable: >=20 > [local count: 1073741824]: > # i_5 =3D PHI <0(8), i_12(3)> > if (i_5 !=3D 200) > goto ; [99.00%] > else > goto ; [1.00%] >=20 > Note that i_5 is known to be 0 on the 8->4 edge. >=20 > The loop info says that bb8 is the pre-header to loop 2 which starts at b= b4.=20 > So this technically crosses loops into bb4, but is allowed as there's an > exception when the first BB is in another block: >=20 > // The first entry represents the block with an outgoing edge > // that we will redirect to the jump threading path. Thus we > // don't care about that block's loop father. So the threading at hand rotates the loop (which is only so-so OK), that might be problematic in case it creates a non-do-while loop after loop header copying. In this process it might also lose track of the loop, causing it to be re-discovered as separate entity which has problems of its own. IMHO we should avoid threadings through a loop header if the path ends in the loop itself, even if it doesn't introduce a new entry but just re-directs the existing one.=