[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:072b2cdb620767c283f1329e95c7d4d35686596e commit r10-11363-g072b2cdb620767c283f1329e95c7d4d35686596e Author: Jakub Jelinek Date: Fri Feb 3 21:37:27 2023 +0100 fortran: Fix up hash table usage in gfc_trans_use_stmts [PR108451] The first testcase in the PR (which I haven't included in the patch because it is unclear to me if it is supposed to be valid or not) ICEs since extra hash table checking has been added recently. The problem is that gfc_trans_use_stmts does tree *slot = entry->decls->find_slot_with_hash (rent->use_name, hash, INSERT); if (*slot == NULL) and later on doesn't store anything into *slot and continues. Another spot a few lines later correctly clears the slot if it decides not to use the slot, so the following patch does the same. 2023-02-03 Jakub Jelinek PR fortran/108451 * trans-decl.c (gfc_trans_use_stmts): Call clear_slot before doing continue. (cherry picked from commit 76f7f0eddcb7c418d1ec3dea3e2341ca99097301)
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:658156714de37163d570ace3a868f23900b0efe9 commit r11-10708-g658156714de37163d570ace3a868f23900b0efe9 Author: Jakub Jelinek Date: Fri Feb 3 21:37:27 2023 +0100 fortran: Fix up hash table usage in gfc_trans_use_stmts [PR108451] The first testcase in the PR (which I haven't included in the patch because it is unclear to me if it is supposed to be valid or not) ICEs since extra hash table checking has been added recently. The problem is that gfc_trans_use_stmts does tree *slot = entry->decls->find_slot_with_hash (rent->use_name, hash, INSERT); if (*slot == NULL) and later on doesn't store anything into *slot and continues. Another spot a few lines later correctly clears the slot if it decides not to use the slot, so the following patch does the same. 2023-02-03 Jakub Jelinek PR fortran/108451 * trans-decl.c (gfc_trans_use_stmts): Call clear_slot before doing continue. (cherry picked from commit 76f7f0eddcb7c418d1ec3dea3e2341ca99097301)
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f2731d1b9a52a7c97af9bbb6ea76603630cc11c2 commit r12-9151-gf2731d1b9a52a7c97af9bbb6ea76603630cc11c2 Author: Jakub Jelinek Date: Fri Feb 3 21:37:27 2023 +0100 fortran: Fix up hash table usage in gfc_trans_use_stmts [PR108451] The first testcase in the PR (which I haven't included in the patch because it is unclear to me if it is supposed to be valid or not) ICEs since extra hash table checking has been added recently. The problem is that gfc_trans_use_stmts does tree *slot = entry->decls->find_slot_with_hash (rent->use_name, hash, INSERT); if (*slot == NULL) and later on doesn't store anything into *slot and continues. Another spot a few lines later correctly clears the slot if it decides not to use the slot, so the following patch does the same. 2023-02-03 Jakub Jelinek PR fortran/108451 * trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before doing continue. (cherry picked from commit 76f7f0eddcb7c418d1ec3dea3e2341ca99097301)
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- The regression (ICE) is now fixed.
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:76f7f0eddcb7c418d1ec3dea3e2341ca99097301 commit r13-5697-g76f7f0eddcb7c418d1ec3dea3e2341ca99097301 Author: Jakub Jelinek Date: Fri Feb 3 21:37:27 2023 +0100 fortran: Fix up hash table usage in gfc_trans_use_stmts [PR108451] The first testcase in the PR (which I haven't included in the patch because it is unclear to me if it is supposed to be valid or not) ICEs since extra hash table checking has been added recently. The problem is that gfc_trans_use_stmts does tree *slot = entry->decls->find_slot_with_hash (rent->use_name, hash, INSERT); if (*slot == NULL) and later on doesn't store anything into *slot and continues. Another spot a few lines later correctly clears the slot if it decides not to use the slot, so the following patch does the same. 2023-02-03 Jakub Jelinek PR fortran/108451 * trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before doing continue.
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> 2023-02-03 Jakub Jelinek
>
> PR fortran/108451
> * trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before
> doing continue.
>
> --- gcc/fortran/trans-decl.cc.jj 2023-01-16 11:52:16.146733136 +0100
> +++ gcc/fortran/trans-decl.cc 2023-02-03 14:41:40.503322954 +0100
> @@ -5350,7 +5350,11 @@ gfc_trans_use_stmts (gfc_namespace * ns)
> /* Sometimes, generic interfaces wind up being over-ruled by a
>local symbol (see PR41062). */
> if (!st->n.sym->attr.use_assoc)
> - continue;
> + {
> + *slot = error_mark_node;
> + entry->decls->clear_slot (slot);
> + continue;
> + }
>
> if (st->n.sym->backend_decl
> && DECL_P (st->n.sym->backend_decl)
>
> fixes the regression (fairly obvious bug). Am not adding testcase because
> given #c1 I'm really not sure if the testcase is valid or not. Anyway, GCC
> 12 accept z1 and z2 and reject z3, so IMHO this bug should be split into the
> checking ICE which the above patch should fix and any possible
> accepts-invalid which doesn't look like a regression.
The code is invalid Fortran. The module m does not contain
an entity named 'pdtt'. If I had to guess the 'pdt' portion
of the name means 'parameterized derived type' and the last
't' means type 't'. This is likely an internal symbol that
has escaped. gfortran's support for PDTs is broken.
I agree with you about committing your fix for the ICE and
opening a new PR about the PDT issue. Note there are already
several open PRs, so this might end up as a dup.
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
2023-02-03 Jakub Jelinek
PR fortran/108451
* trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before
doing continue.
--- gcc/fortran/trans-decl.cc.jj2023-01-16 11:52:16.146733136 +0100
+++ gcc/fortran/trans-decl.cc 2023-02-03 14:41:40.503322954 +0100
@@ -5350,7 +5350,11 @@ gfc_trans_use_stmts (gfc_namespace * ns)
/* Sometimes, generic interfaces wind up being over-ruled by a
local symbol (see PR41062). */
if (!st->n.sym->attr.use_assoc)
- continue;
+ {
+ *slot = error_mark_node;
+ entry->decls->clear_slot (slot);
+ continue;
+ }
if (st->n.sym->backend_decl
&& DECL_P (st->n.sym->backend_decl)
fixes the regression (fairly obvious bug). Am not adding testcase because
given #c1 I'm really not sure if the testcase is valid or not. Anyway, GCC 12
accept z1 and z2 and reject z3, so IMHO this bug should be split into the
checking ICE which the above patch should fix and any possible accepts-invalid
which doesn't look like a regression.
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2023-01-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- It's been there since Alexander's revision r13-4937-g012fdbc14233fbb4.
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 CC||aoliva at gcc dot gnu.org
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 G. Steinmetz changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Following variant z2 should be rejected similar to z3 : $ cat z2.f90 module m type t(n) integer, len :: n integer :: a(n) end type contains subroutine s(x) type(t(2)) :: x end end program p use m, only: t, s, pdtt type(t(2)) :: y call s(y) end $ cat z3.f90 module m type t end type contains subroutine s end end program p use m, only: t, s, pdtt call s end $ gfortran-13-20230115 -c z2.f90 # missing error $ $ gfortran-13-20230115 -c z3.f90 z3.f90:9:21: 9 |use m, only: t, s, pdtt | 1 Error: Symbol 'pdtt' referenced at (1) not found in module 'm'
