[Bug fortran/107075] New: ICE in get, at cgraph.h:461

[Bug fortran/107075] New: ICE in get, at cgraph.h:461

[gscfq@t-online.de]

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

[Bug fortran/107075] ICE in get, at cgraph.h:461

[anlauf at gcc dot gnu.org]

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 .

[Bug fortran/107075] ICE in get, at cgraph.h:461

[rguenth at gcc dot gnu.org]

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 ...

[Bug fortran/107075] ICE in get, at cgraph.h:461

[mikael at gcc dot gnu.org]

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.

[Bug fortran/107075] ICE in get, at cgraph.h:461

[anlauf at gcc dot gnu.org]

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

[Bug fortran/107075] ICE in get, at cgraph.h:461

[anlauf at gcc dot gnu.org]

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.

[Bug fortran/107075] ICE in get, at cgraph.h:461

[anlauf at gcc dot gnu.org]

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;
 }