Started recently between 20221218 and 20230108, with special name pdtt : (gcc configured with --enable-checking=yes) $ cat z1.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, pdtt, s type(t(2)) :: y call s(y) end $ gfortran-13-20221218 -c z1.f90 # missing error $ $ gfortran-13-20230115 -c z1.f90 z1.f90:12:7: 12 | use m, only: t, pdtt, s | 1 internal compiler error: in check_complete_insertion, at hash-table.h:578 0x92fc0b hash_table<module_decl_hasher, false, xcallocator>::check_complete_insertion() const ../../gcc/hash-table.h:578 0x92fc0b hash_table<module_decl_hasher, false, xcallocator>::find_slot_with_hash(char const* const&, unsigned int, insert_option) ../../gcc/hash-table.h:1042 0x92c57e gfc_trans_use_stmts ../../gcc/fortran/trans-decl.cc:5329 0x92d3a6 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7837 0x89ef8e translate_all_program_units ../../gcc/fortran/parse.cc:6721 0x89ef8e gfc_parse_file() ../../gcc/fortran/parse.cc:7027 0x8ed3af gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
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'
It's been there since Alexander's revision r13-4937-g012fdbc14233fbb4.
2023-02-03 Jakub Jelinek <jakub@redhat.com> 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.
(In reply to Jakub Jelinek from comment #3) > 2023-02-03 Jakub Jelinek <jakub@redhat.com> > > 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.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:76f7f0eddcb7c418d1ec3dea3e2341ca99097301 commit r13-5697-g76f7f0eddcb7c418d1ec3dea3e2341ca99097301 Author: Jakub Jelinek <jakub@redhat.com> 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 <jakub@redhat.com> PR fortran/108451 * trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before doing continue.
The regression (ICE) is now fixed.
The releases/gcc-12 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:f2731d1b9a52a7c97af9bbb6ea76603630cc11c2 commit r12-9151-gf2731d1b9a52a7c97af9bbb6ea76603630cc11c2 Author: Jakub Jelinek <jakub@redhat.com> 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 <jakub@redhat.com> PR fortran/108451 * trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before doing continue. (cherry picked from commit 76f7f0eddcb7c418d1ec3dea3e2341ca99097301)
The releases/gcc-11 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:658156714de37163d570ace3a868f23900b0efe9 commit r11-10708-g658156714de37163d570ace3a868f23900b0efe9 Author: Jakub Jelinek <jakub@redhat.com> 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 <jakub@redhat.com> PR fortran/108451 * trans-decl.c (gfc_trans_use_stmts): Call clear_slot before doing continue. (cherry picked from commit 76f7f0eddcb7c418d1ec3dea3e2341ca99097301)
The releases/gcc-10 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:072b2cdb620767c283f1329e95c7d4d35686596e commit r10-11363-g072b2cdb620767c283f1329e95c7d4d35686596e Author: Jakub Jelinek <jakub@redhat.com> 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 <jakub@redhat.com> PR fortran/108451 * trans-decl.c (gfc_trans_use_stmts): Call clear_slot before doing continue. (cherry picked from commit 76f7f0eddcb7c418d1ec3dea3e2341ca99097301)