* [Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
2023-01-18 18:24 [Bug fortran/108451] New: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578 gscfq@t-online.de
@ 2023-01-18 18:25 ` gscfq@t-online.de
2023-01-19 7:47 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: gscfq@t-online.de @ 2023-01-18 18:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
G. Steinmetz <gscfq@t-online.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |accepts-invalid,
| |ice-on-invalid-code
--- Comment #1 from G. Steinmetz <gscfq@t-online.de> ---
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'
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
2023-01-18 18:24 [Bug fortran/108451] New: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578 gscfq@t-online.de
2023-01-18 18:25 ` [Bug fortran/108451] " gscfq@t-online.de
@ 2023-01-19 7:47 ` rguenth at gcc dot gnu.org
2023-01-19 14:22 ` marxin at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-19 7:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |13.0
CC| |aoliva at gcc dot gnu.org
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
2023-01-18 18:24 [Bug fortran/108451] New: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578 gscfq@t-online.de
2023-01-18 18:25 ` [Bug fortran/108451] " gscfq@t-online.de
2023-01-19 7:47 ` rguenth at gcc dot gnu.org
@ 2023-01-19 14:22 ` marxin at gcc dot gnu.org
2023-02-03 13:50 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-01-19 14:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
Martin Liška <marxin at gcc dot gnu.org> 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 <marxin at gcc dot gnu.org> ---
It's been there since Alexander's revision r13-4937-g012fdbc14233fbb4.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
2023-01-18 18:24 [Bug fortran/108451] New: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578 gscfq@t-online.de
` (2 preceding siblings ...)
2023-01-19 14:22 ` marxin at gcc dot gnu.org
@ 2023-02-03 13:50 ` jakub at gcc dot gnu.org
2023-02-03 17:07 ` kargl at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-03 13:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
2023-01-18 18:24 [Bug fortran/108451] New: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578 gscfq@t-online.de
` (3 preceding siblings ...)
2023-02-03 13:50 ` jakub at gcc dot gnu.org
@ 2023-02-03 17:07 ` kargl at gcc dot gnu.org
2023-02-03 20:38 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-02-03 17:07 UTC (permalink / raw)
To: gcc-bugs
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 <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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
2023-01-18 18:24 [Bug fortran/108451] New: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578 gscfq@t-online.de
` (4 preceding siblings ...)
2023-02-03 17:07 ` kargl at gcc dot gnu.org
@ 2023-02-03 20:38 ` cvs-commit at gcc dot gnu.org
2023-02-03 20:41 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-02-03 20:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
2023-01-18 18:24 [Bug fortran/108451] New: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578 gscfq@t-online.de
` (5 preceding siblings ...)
2023-02-03 20:38 ` cvs-commit at gcc dot gnu.org
@ 2023-02-03 20:41 ` jakub at gcc dot gnu.org
2023-02-10 17:46 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-03 20:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The regression (ICE) is now fixed.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
2023-01-18 18:24 [Bug fortran/108451] New: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578 gscfq@t-online.de
` (6 preceding siblings ...)
2023-02-03 20:41 ` jakub at gcc dot gnu.org
@ 2023-02-10 17:46 ` cvs-commit at gcc dot gnu.org
2023-05-02 20:14 ` cvs-commit at gcc dot gnu.org
2023-05-03 15:21 ` cvs-commit at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-02-10 17:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
2023-01-18 18:24 [Bug fortran/108451] New: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578 gscfq@t-online.de
` (7 preceding siblings ...)
2023-02-10 17:46 ` cvs-commit at gcc dot gnu.org
@ 2023-05-02 20:14 ` cvs-commit at gcc dot gnu.org
2023-05-03 15:21 ` cvs-commit at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-02 20:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
2023-01-18 18:24 [Bug fortran/108451] New: [13 Regression] ICE in check_complete_insertion, at hash-table.h:578 gscfq@t-online.de
` (8 preceding siblings ...)
2023-05-02 20:14 ` cvs-commit at gcc dot gnu.org
@ 2023-05-03 15:21 ` cvs-commit at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-05-03 15:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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)
^ permalink raw reply [flat|nested] 11+ messages in thread