https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108512
Bug ID: 108512
Summary: [13 Regression][OpenMP] ICE for valid loop
data-sharing clauses
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp, rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jules at gcc dot gnu.org
Target Milestone: ---
I bet this is revealed/"caused" by PR107214's
commit r13-4703-g330b9a8d87dd73e10539da618496ad4964fee26d
even if that commit is not wrong.
The harmlessly looking
https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.0/loop/test_loop_lastprivate.F90
now gives an ICE.
The problem occurs for:
+ gfc_error ("Symbol %qs present on multiple clauses at %L",
+ n->sym->name, &n->where);
There seem to be two issues:
(A) 'n->where' is NULL, causing the ICE.
(B) The code is actually valid.
I think the following patch fixes the 'n->where' problem; I have not checked
whether one could give it a better location.
However, the real problem is that 'x' is now in both OMP_LIST_PRIVATE due to
gfc_resolve_do_iterator and explicitly by the user in the LASTPRIVATE clause.
I have not really understood what the function is doing and whether it is
needed. But the PRIVATE clause part somehow looks "wrong".
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -9225,4 +9225,5 @@ (gfc_code *code, gfc_symbol
p = gfc_get_omp_namelist ();
p->sym = sym;
+ p->where = code->loc;
p->next = omp_clauses->lists[OMP_LIST_PRIVATE];
omp_clauses->lists[OMP_LIST_PRIVATE] = p;
