From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 584643858D35; Tue, 7 Feb 2023 11:28:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 584643858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1675769309; bh=gEU6D5VdCj8HI9nccu4qovAUinF84r0Stfnl5iWarLE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=W35BuIGDc8u9FrLX0fbnXGmUz4y+ds5+Z7xF0KpfkDZBYfgQw7oFZDm91I4lMf/Su v8JsOs9pr4UzgBwjxUZT+o9skj/DrWtg+X7G7xmeXE+9ornpSZtl4II4NjsoxRYcsS zdLhCHt8jWYTPSeXNIcKgc5yNIfmXA5uIWko9k7Y= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/108656] [12/13 Regression] '-fcompare-debug' failure (length) w/ -O2 -fno-ipa-pure-const -fno-tree-dce --param early-inlining-insns=0 since r12-5236 Date: Tue, 07 Feb 2023 11:28:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: compare-debug-failure X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de 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: 12.3 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108656 --- Comment #13 from rguenther at suse dot de --- On Mon, 6 Feb 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108656 >=20 > --- Comment #12 from Jakub Jelinek --- > (In reply to rguenther@suse.de from comment #11) > > On Mon, 6 Feb 2023, jakub at gcc dot gnu.org wrote: > >=20 > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108656 > > >=20 > > > --- Comment #10 from Jakub Jelinek --- > > > Anyway, if we decided that it is ok to have just the incoming ab edge= s, we'd > > > need to change any code that can DCE or inline calls to update abnorm= al edges > > > not just for the case where the last stmt used to be can_make_abnorma= l_goto and > > > no longer is, but also for the case when the first stmt was returns_t= wice call > > > and no longer is, in that case we'd need to drop that abnormal edge p= ointing to > > > the start of the bb from the .ABNORMAL_DISPATCHER block. > >=20 > > Doesn't cleanup CFG do this via removal of the unreachable=20 > > .ABNORMAL_DISPATCHER? >=20 > If all non-pure calls are removed (all can_make_abnormal_goto to be preci= se), > sure. Or if we reset and recompute cfun->calls_setjmp and then do cfg cl= eanup. > The problem on the above testcase is that it can never happen or takes ma= ny > passes. > The returns_twice function is gone during einline pass, but there are oth= er > calls that can make abnormal goto (well, have side-effects and nothing no= ticed > we don't have any returns_twice calls anymore). So we have an ab edge po= inting > to a bb that doesn't start with returns_twice function, that alone looks = wrong > to me. During IPA we then inline further functions and diverge on when we > trigger the removal on outgoing abnormal edges because of debug stmts. I've fixed a lot of issues like this, even implemented a verifier, but=20 that's still too trigger happy. So yes, there are some issues left and the only hard assert I've put in is the DCE one that makes sure abnormal dispatchers are not discovered "late".=