From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 82BF93858C60; Wed, 15 Feb 2023 15:15:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 82BF93858C60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1676474126; bh=B3+xN+H/Mi8ugcnVrAVAsivIG1VxHsp02Ta9VXOLe1o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VRQqlpAbP7RM3BcxGoJcmMvzZW4usbHoRQiZRLtDEjgKas9+ngtWc3vw79GizS7mB squthqV9dLxKKuvs9mBggcQddhRA5qVODmhcRtks6N3NK//QR+HiO5D12OV5F5k060 4Yd0CvzR6sfjQGionDeIp17BgBpFWi+MlKwdyPsU= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da Date: Wed, 15 Feb 2023 15:15:26 +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: 13.0 X-Bugzilla-Keywords: ice-checking, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org 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: 10.5 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=3D108685 --- Comment #4 from Jakub Jelinek --- expand_omp_for_generic like other ompexp functions has the notion of broken_loop for loops where the body doesn't fall through to the artificial #pragma omp continue. This works fine even for doacross loops if they have ordered equals collaps= e or all the loops between ordered (inclusive) and collapse (exclusive) have com= pile time constant non-zero number of iterations. The problem is when they could have zero iterations (as in the testcase) or= do have those provably - say if l < a above is replaced with l < -2, in that c= ase while the ultimate body is a broken loop, either conditionally or always th= at ultimate body will not be encountered at runtime at all, and the loop will = do nothing at all. In that case the loop is no longer a non-loop (broken_loop) because in some cases or all= it can actually loop. We can I think detect that after the expand_omp_for_init_counts call in expand_omp_for_generic. The question is if we at that point can add an artificial cont_bb somewhere, set broken_loop to false and do whatever is needed to make the rest of the function work as if it wasn't a broken loop.=