From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C867D3858C78; Fri, 4 Feb 2022 11:46:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C867D3858C78 From: "tschwinge at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/102330] [12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932 since r12-980-g29a2f51806c Date: Fri, 04 Feb 2022 11:46:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: ice-on-valid-code, openacc, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: tschwinge at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: tschwinge at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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, 04 Feb 2022 11:46:33 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102330 Thomas Schwinge changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rguenth at gcc dot gnu.org --- Comment #8 from Thomas Schwinge --- Posting my current status here, in case anybody feels like verifying my thoughts. :-) So I'm looking into Jakub's last, simplest reproducer: (In reply to Jakub Jelinek from comment #7) > program p > i =3D 0 > !$omp task shared(i) > i =3D 1 > !$omp end task > !$omp taskwait > !$acc parallel loop > do i =3D 1, 8 > end do > end >=20 > also ICEs ACK. > it just needs the iterator that is marked addressable during > omp-low.c which has code to regimplify statements that access such > variables, but it seems the problematic stmts are emitted only during > omp-expand.c. ACK, 'gcc/omp-expand.cc:expand_oacc_for'. > The various expand_omp_* loop expansions have DECL_P (...) && > TREE_ADDRESSABLE (...) conditions in various spots, but perhaps OpenACC l= oop > expansion doesn't. (Thanks, that has help me with PR104132!) However, that doesn't seem to be the problem here: we get reported "non-register as LHS of binary operation", but we've got in 'gcc/omp-expand.cc:expand_oacc_for': 7868 ass =3D gimple_build_assign (v, expr); (gdb) n 7869 gsi_insert_before (&gsi, ass, GSI_SAME_STMT); (gdb) call debug_gimple_stmt(ass) i =3D 1 + .offset.8; (gdb) call debug_tree(v) unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-ty= pe 0x7ffff75555e8 precision:32 min max pointer_to_this > used SI source-gcc/gcc/testsuite/gfortran.dg/goacc-gomp/pr102330-3.f90:9:3 size unit-size align:32 warn_if_not_align:0 context > (gdb) call is_gimple_lvalue(v) $4 =3D true (gdb) call is_gimple_reg(v) $5 =3D true (gdb) print v.base.addressable_flag=20 $6 =3D 0 So, 'i' is not 'TREE_ADDRESSABLE'. Is the problem rather, that we earlier have done wrong, as Richard pointed = out: (In reply to Richard Biener from comment #1) > Confirmed. omp expansion seems to introudce this non-gimple code and lik= ely also makes 'i' not a register (for OACC): >=20 > .data_dep.5D.4044 =3D .UNIQUE (OACC_PRIVATE, .data_dep.5D.4044, -1, &iD= .4045); That's built in 'gcc/omp-low.cc:lower_oacc_private_marker'. It's not marked 'TREE_ADDRESSABLE' (per debug log above), but the address of 'i' has been t= aken (here). > but >=20 > iD.4045 =3D 1 + .offset.9D.4049; >=20 > and >=20 > iD.4045 =3D 1 + 8; >=20 > (which is also unfolded) Assuming 'TREE_ADDRESSABLE', that last item is resolved via my proposed PR104132 change: [...] +gimple_simplified to D.4257 =3D 9; [...] - iD.4257 =3D 1 + 8; + D.4266 =3D 9; + iD.4259 =3D D.4266; [...] So if in 'gcc/omp-expand.cc:expand_oacc_for' I force 'TREE_ADDRESSABLE', th= en the ICE goes away, and we get valid GIMPLE generated, per my understanding. So, something like this maybe (untested)?=20=20 --- gcc/omp-low.cc +++ gcc/omp-low.cc @@ -11513,6 +11513,7 @@ lower_oacc_private_marker (omp_context *ctx) } gcc_checking_assert (decl); + TREE_ADDRESSABLE (decl) =3D 1; tree addr =3D build_fold_addr_expr (decl); args.safe_push (addr); } However: given that the '#pragma acc loop' has an implicit 'private(i)' -- = why does the 'gcc/omp-expand.cc:expand_oacc_for' even bother about the "outer '= i'"? The loop variable 'i' should be a completely separate, local, register-like temporary. Amy I misunderstanding something, or what's going wrong, elsewh= ere?=