From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C06FD3858C53; Thu, 14 Apr 2022 10:55:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C06FD3858C53 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0 Date: Thu, 14 Apr 2022 10:55:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-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: Thu, 14 Apr 2022 10:55:04 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105231 --- Comment #27 from rguenther at suse dot de --- On Thu, 14 Apr 2022, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105231 >=20 > --- Comment #26 from Segher Boessenkool --- > (In reply to Richard Biener from comment #25) > > (In reply to Segher Boessenkool from comment #24) > > > Wrt keeping REG_EQUAL notes... If you want to keep them you need to = make > > > sure > > > they still are valid. GCC keeps those on i3, it is much too hard in = general > > > to > > > validate other such notes. > >=20 > > It seems to be that the REG_EQUAL notes of the SET dests in the final > > instruction we combine into, so 24 for > >=20 > > Trying 78, 17 -> 24: > >=20 > > are better always valid even after the combination - at least when they > > are not refering to pseudos set by insns combined (78, 17 here) and alw= ays > > when the REG_EQUAL is constant. When there are multiple sets in the fi= nal > > insn (24) then which note ends up where is determined by the SET dests. >=20 > In the *resulting* final insn. And some of those notes may have to be mo= ved > to i2 -- when there are multiple sets in the *resulting* insn, and it is = split. >=20 > > For this particular case preserving _constant_ REG_EQUAL notes would be > > important. And for this case only handling single-set would be good en= ough. >=20 > You can *never* require REG_EQUAL notes for correctness. It is always co= rrect > to delete REG_EQUAL notes. They exist to make optimisation easier, and f= or > nothing else. >=20 > > Of course if i3 is not always '24' (in this case) then we have to find > > a better place to preserve these than distribute_notes. >=20 > Or fix the bug: that which requires REG_EQUAL notes to not be deleted. T= his > is a problem whether or not we hide the problem here (by making things > optimised better). Then the bug is in combine itself - it places a REG_EH_REGION note but fails to split the basic-block after the affected=20 instruction. Or it even considers placing it on the not last instruction. Maybe there's already the constraint that combine never combines an insns with a REG_EH_REGION note (aka a possibly throwing insn) with another but only combines not throwing insns into a throwing one. Then the correct action is to always place the REG_EH_REGION note on the last insn, or if that cannot throw, throw it away. If we somehow created an intermediate throwing/trapping insn we should then reject the combination. Richard.=