public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/107075] New: ICE in get, at cgraph.h:461
@ 2022-09-28 17:36 gscfq@t-online.de
2022-09-28 20:13 ` [Bug fortran/107075] " anlauf at gcc dot gnu.org
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: gscfq@t-online.de @ 2022-09-28 17:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075
Bug ID: 107075
Summary: ICE in get, at cgraph.h:461
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gscfq@t-online.de
Target Milestone: ---
Affects versions down to at least r5 :
(both valid, works without block construct)
$ cat z1.f90
program p
implicit none
integer, target :: a(3)
block
integer, pointer :: z => a(2)
a = [1, 2, 3]
z = 7
print *, a, z
end block
end
$ cat z2.f90
program p
implicit none
integer, target :: a(3)
integer, pointer :: z => a(2)
a = [1, 2, 3]
z = 7
print *, a, z
end
$ gfortran-13-20220925 z2.f90 && ./a.out
1 7 3 7
$ gfortran-13-20220925 -c z1.f90
f951: internal compiler error: in get, at cgraph.h:461
0x131212f symtab_node::get(tree_node const*)
../../gcc/cgraph.h:458
0x131212f varpool_node::get(tree_node const*)
../../gcc/cgraph.h:2785
0x131212f varpool_node::get_create(tree_node*)
../../gcc/varpool.cc:145
0xa1e20f record_reference
../../gcc/cgraphbuild.cc:82
0x12ad193 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*))
../../gcc/tree.cc:11249
0xa1ecb5 record_references_in_initializer(tree_node*, bool)
../../gcc/cgraphbuild.cc:386
0x1313037 varpool_node::analyze()
../../gcc/varpool.cc:537
0xa2506e analyze_functions
../../gcc/cgraphunit.cc:1294
0xa2624d symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2500
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/107075] ICE in get, at cgraph.h:461
2022-09-28 17:36 [Bug fortran/107075] New: ICE in get, at cgraph.h:461 gscfq@t-online.de
@ 2022-09-28 20:13 ` anlauf at gcc dot gnu.org
2022-09-29 8:17 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-09-28 20:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-09-28
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
Small variation:
program p
implicit none
integer, target :: a(3)
! save :: a
a = [1, 2, 3]
block
integer, pointer :: z => a(2)
z = 7
end block
end
Uncommenting the 'save' also avoids the ICE, as does adding -fno-automatic .
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/107075] ICE in get, at cgraph.h:461
2022-09-28 17:36 [Bug fortran/107075] New: ICE in get, at cgraph.h:461 gscfq@t-online.de
2022-09-28 20:13 ` [Bug fortran/107075] " anlauf at gcc dot gnu.org
@ 2022-09-29 8:17 ` rguenth at gcc dot gnu.org
2022-09-29 9:05 ` mikael at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-09-29 8:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's a static variable ('z') with an initializer that refers to an automatic
variable ('a').
The appropriate way to runtime initialize is not with DECL_INITIAL but
instead with an INIT_EXPR or MODIFY_EXPR.
But maybe 'z' shouldn't be of static storage duration ...
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/107075] ICE in get, at cgraph.h:461
2022-09-28 17:36 [Bug fortran/107075] New: ICE in get, at cgraph.h:461 gscfq@t-online.de
2022-09-28 20:13 ` [Bug fortran/107075] " anlauf at gcc dot gnu.org
2022-09-29 8:17 ` rguenth at gcc dot gnu.org
@ 2022-09-29 9:05 ` mikael at gcc dot gnu.org
2022-09-29 21:16 ` anlauf at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: mikael at gcc dot gnu.org @ 2022-09-29 9:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #3 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #1)
>
> Uncommenting the 'save' also avoids the ICE, as does adding -fno-automatic .
... as does adding an initializer to A.
That's something I noticed just a few days ago: variables from main program
without initializer don't get (implicitly) the SAVE attribute.
(In reply to Richard Biener from comment #2)
>
> But maybe 'z' shouldn't be of static storage duration ...
No, I think it shouldn't. A should be static, and Z should not.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/107075] ICE in get, at cgraph.h:461
2022-09-28 17:36 [Bug fortran/107075] New: ICE in get, at cgraph.h:461 gscfq@t-online.de
` (2 preceding siblings ...)
2022-09-29 9:05 ` mikael at gcc dot gnu.org
@ 2022-09-29 21:16 ` anlauf at gcc dot gnu.org
2022-10-06 18:02 ` anlauf at gcc dot gnu.org
2022-10-06 19:19 ` anlauf at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-09-29 21:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #3)
> (In reply to Richard Biener from comment #2)
> >
> > But maybe 'z' shouldn't be of static storage duration ...
>
> No, I think it shouldn't. A should be static, and Z should not.
Well, I think the declaration
integer, pointer :: z => a(2)
makes pointer z IMPLICIT_SAVE. At least I couldn't find anything in the
standard that makes an exception for declarations in a BLOCK construct.
This is confirmed by Intel and Cray and by replacing 'program p'
by 'subroutine p'. And in line with gfortran...
Error: Pointer initialization target at (1) must have the SAVE attribute
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/107075] ICE in get, at cgraph.h:461
2022-09-28 17:36 [Bug fortran/107075] New: ICE in get, at cgraph.h:461 gscfq@t-online.de
` (3 preceding siblings ...)
2022-09-29 21:16 ` anlauf at gcc dot gnu.org
@ 2022-10-06 18:02 ` anlauf at gcc dot gnu.org
2022-10-06 19:19 ` anlauf at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-10-06 18:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075
--- Comment #5 from anlauf at gcc dot gnu.org ---
There is a check in expr.cc:2623 that is reached if one changes the
testcase to a subroutine, but not if it is a program:
4615 if (!attr.save && rvalue->expr_type == EXPR_VARIABLE
4616 && rvalue->symtree->n.sym->ns->proc_name
4617 &&
rvalue->symtree->n.sym->ns->proc_name->attr.is_main_program)
4618 {
4619 rvalue->symtree->n.sym->ns->proc_name->attr.save =
SAVE_IMPLICIT;
4620 attr.save = SAVE_IMPLICIT;
4621 }
4622
4623 if (!attr.save)
4624 {
4625 gfc_error ("Pointer initialization target at %L "
4626 "must have the SAVE attribute", &rvalue->where);
4627 return false;
4628 }
I think the first check tries to fake that the target has the right
attributes in a main program (implicit save) while it hasn't.
If we fix the attributes of variables in the main program, the above
check should be revisited.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/107075] ICE in get, at cgraph.h:461
2022-09-28 17:36 [Bug fortran/107075] New: ICE in get, at cgraph.h:461 gscfq@t-online.de
` (4 preceding siblings ...)
2022-10-06 18:02 ` anlauf at gcc dot gnu.org
@ 2022-10-06 19:19 ` anlauf at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: anlauf at gcc dot gnu.org @ 2022-10-06 19:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075
--- Comment #6 from anlauf at gcc dot gnu.org ---
I tried the following patch, which however regresses on a couple testcases:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index d9d101775f6..cfc6fc055bd 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -16349,6 +16349,16 @@ resolve_symbol (gfc_symbol *sym)
if (sym->param_list)
resolve_pdt (sym);
+
+ if (sym->attr.flavor == FL_VARIABLE
+ && sym->attr.save == SAVE_NONE
+ && !sym->attr.allocatable
+ && !sym->attr.pointer
+ && !sym->attr.class_pointer
+ && sym->ns->proc_name
+ && sym->ns->proc_name->attr.flavor == FL_PROGRAM
+ && sym->ns->proc_name->attr.is_main_program)
+ sym->attr.save = SAVE_IMPLICIT;
}
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-10-06 19:19 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-28 17:36 [Bug fortran/107075] New: ICE in get, at cgraph.h:461 gscfq@t-online.de
2022-09-28 20:13 ` [Bug fortran/107075] " anlauf at gcc dot gnu.org
2022-09-29 8:17 ` rguenth at gcc dot gnu.org
2022-09-29 9:05 ` mikael at gcc dot gnu.org
2022-09-29 21:16 ` anlauf at gcc dot gnu.org
2022-10-06 18:02 ` anlauf at gcc dot gnu.org
2022-10-06 19:19 ` anlauf at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).