From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B99F53857BB7; Fri, 23 Sep 2022 15:23:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B99F53857BB7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663946598; bh=MqHvfxnEaDqCiD5NHK9DS0ppz0c+QEao/LFjsYDoks4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nHIzO8bnb/Ao+1QOAS50vcXHRd8TWuot14etPI6BxtILhqj+yJ16Eb/PA1QEiUUIi AXLPWRqtciiPtpz9eYbqA57q5Okq2uuN+E0534UxUDKxXPwBCLMXQFueKnzyeipVhG dVaGffB5yOGteWeGc+i8xmG1G8IQ6L0wiP1etqT0= From: "tschwinge at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/102310] [11/12/13 Regression] ICE in visit_ref_for_mod_analysis with OpenACC Date: Fri, 23 Sep 2022 15:23:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: ice-on-valid-code, openacc X-Bugzilla-Severity: normal X-Bugzilla-Who: tschwinge at gcc dot gnu.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: 11.4 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=3D102310 --- Comment #8 from Thomas Schwinge --- I found that the '-O2' ICE 'during IPA pass: cp' originally reported here as well as the '-O0' ICE 'during RTL pass: expand' do disappear with Julian's recent r13-2665-g23baa717c991d77f206a9358ce2c04960ccf9eea "OpenMP/OpenACC struct sibling list gimplification extension and rework". I can't tell if Julian's commit indeed does fix the underlying problem, or = if it just hides it. However: (In reply to Martin Jambor from comment #6) > [...] IL includes a PARM_DECL of a different function. So I suspect [...] >From a quick before/after 'diff' of the 'gimple' dump, indeed I do see chan= ges re 'PARM_DECL's, but also changes in the 'map' clauses. It seems as if the latter may be mandating the former, but I've not looked in detail.=