[Bug fortran/99139] New: ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

[Bug fortran/99139] New: ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

[gscfq@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139

            Bug ID: 99139
           Summary: ICE: gfc_get_default_type(): Bad symbol
                    '__tmp_UNKNOWN_0_rank_1'
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Started between 20190825 and 20190901 :


$ cat z1.f90
subroutine s(x)
   target :: x(..)
   select rank (y => x)
   rank (1)
   rank (2)
   end select
end


$ gfortran-11-20210214 -c z1.f90
f951: internal compiler error: gfc_get_default_type(): Bad symbol
'__tmp_UNKNOWN_0_rank_1'
0x687519 gfc_report_diagnostic
        ../../gcc/fortran/error.c:782
0x688c3a gfc_internal_error(char const*, ...)
        ../../gcc/fortran/error.c:1402
0x7206dc gfc_get_default_type(char const*, gfc_namespace*)
        ../../gcc/fortran/symbol.c:239
0x724408 gfc_set_default_type(gfc_symbol*, int, gfc_namespace*)
        ../../gcc/fortran/symbol.c:298
0x6ff33c resolve_symbol
        ../../gcc/fortran/resolve.c:15380
0x71e2c2 do_traverse_symtree
        ../../gcc/fortran/symbol.c:4170
0x702bb4 resolve_types
        ../../gcc/fortran/resolve.c:17296
0x6fe22c gfc_resolve(gfc_namespace*)
        ../../gcc/fortran/resolve.c:17411
0x6fd667 gfc_resolve(gfc_namespace*)
        ../../gcc/fortran/resolve.c:11720
0x6fd667 resolve_select_rank
        ../../gcc/fortran/resolve.c:9717
0x6fd667 gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.c:12055
0x6fe177 resolve_codes
        ../../gcc/fortran/resolve.c:17378
0x6fe23e gfc_resolve(gfc_namespace*)
        ../../gcc/fortran/resolve.c:17413
0x6e6784 resolve_all_program_units
        ../../gcc/fortran/parse.c:6290
0x6e6784 gfc_parse_file()
        ../../gcc/fortran/parse.c:6542
0x7330ff gfc_be_parse_file
        ../../gcc/fortran/f95-lang.c:212

[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

[gscfq@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139

G. Steinmetz <gscfq@t-online.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code

--- Comment #1 from G. Steinmetz <gscfq@t-online.de> ---

This variant compiles ...

$ cat z0.f90
subroutine s(x)
   real, target :: x(..)
   select rank (y => x)
   rank (1)
   rank (2)
   end select
end

$ gfortran-11-20210214 -c z0.f90
$


... with one exception :

$ gfortran-11-20210214 -c z0.f90 -finit-local-zero  # or -finit-real=snan
z0.f90:3:22:

    3 |    select rank (y => x)
      |                      1
Error: Assumed-rank variable y at (1) may only be used as actual argument

[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
   Last reconfirmed|                            |2021-02-17
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P4

--- Comment #2 from kargl at gcc dot gnu.org ---
Fixes problem with original code.  Not regression tested.

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 2df6191d7e6..eb51b9905da 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -6634,6 +6639,18 @@ gfc_match_select_rank (void)

   gfc_current_ns = gfc_build_block_ns (ns);
   m = gfc_match (" %n => %e", name, &expr2);
+
+  /* If expr2 corresponds to an implicitly typed variable, then the actual
+     type of the variable may not have been resolved.  Set it here.  */
+  if (!gfc_current_ns->seen_implicit_none
+      && expr2->expr_type == EXPR_VARIABLE
+      && expr2->ts.type == BT_UNKNOWN
+      && expr2->symtree && expr2->symtree->n.sym)
+    {
+      gfc_set_default_type (expr2->symtree->n.sym, 0, gfc_current_ns);
+      expr2->ts.type = expr2->symtree->n.sym->ts.type;
+    }
+    
   if (m == MATCH_YES)
     {
       expr1 = gfc_get_expr ();

[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r10-2912-g70570ec192745095.

[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

[sandra at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139

sandra at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandra at gcc dot gnu.org

--- Comment #4 from sandra at gcc dot gnu.org ---
The problem noted in comment 1 looks related to PR 102641 --
automatically-inserted implicit initialization code can't cope with
assumed-rank arrays.

I tested the patch in comment 2 and saw a whole lot of regressions (ICEs).  :-(

[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to sandra from comment #4)
> The problem noted in comment 1 looks related to PR 102641 --
> automatically-inserted implicit initialization code can't cope with
> assumed-rank arrays.

I don't think it is related.  PR102601 involves default initialization
and/or deallocation of an actual argument associated with an intent(out)
assumed-rank dummy argument.

> I tested the patch in comment 2 and saw a whole lot of regressions (ICEs). 
> :-(

The patch in comment #2 needed to be moved down into the 'if (m == MATCH_YES)'
block where 'expr2 != NULL'.  The following has been regtested with no new
regressions.

diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 5eb6d0e1c1d..0a030ae01df 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -6770,8 +6770,20 @@ gfc_match_select_rank (void)

   gfc_current_ns = gfc_build_block_ns (ns);
   m = gfc_match (" %n => %e", name, &expr2);
+
   if (m == MATCH_YES)
     {
+      /* If expr2 corresponds to an implicitly typed variable, then the
+        actual type of the variable may not have been set.  Set it here.  */
+      if (!gfc_current_ns->seen_implicit_none 
+         && expr2->expr_type == EXPR_VARIABLE
+         && expr2->ts.type == BT_UNKNOWN
+         && expr2->symtree && expr2->symtree->n.sym)
+       {
+         gfc_set_default_type (expr2->symtree->n.sym, 0, gfc_current_ns);
+         expr2->ts.type = expr2->symtree->n.sym->ts.type;
+       }    
+
       expr1 = gfc_get_expr ();
       expr1->expr_type = EXPR_VARIABLE;
       expr1->where = expr2->where;

[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:9a2eab6172a8067e2f63e0fa2bcd5b2190656303

commit r14-2397-g9a2eab6172a8067e2f63e0fa2bcd5b2190656303
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Jul 8 18:13:23 2023 +0100

    Fortran: Fix default type bugs in gfortran [PR99139, PR99368]

    2023-07-08  Steve Kargl  <sgk@troutmask.apl.washington.edu>

    gcc/fortran
            PR fortran/99139
            PR fortran/99368
            * match.cc (gfc_match_namelist): Check for host associated or
            defined types before applying default type.
            (gfc_match_select_rank): Apply default type to selector of
            unknown type if possible.
            * resolve.cc (resolve_fl_variable): Do not apply local default
            initialization to assumed rank entities.

    gcc/testsuite/
            PR fortran/99139
            * gfortran.dg/pr99139.f90 : New test

            PR fortran/99368
            * gfortran.dg/pr99368.f90 : New test

[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |10.5.0, 11.4.0, 12.3.0,
                   |                            |13.1.0
      Known to work|                            |14.0

--- Comment #7 from anlauf at gcc dot gnu.org ---
Updating known-to-work/known to fail version.

Paul/Steve: do you want to assign this PR to one of you?

[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to anlauf from comment #7)
> Updating known-to-work/known to fail version.
> 
> Paul/Steve: do you want to assign this PR to one of you?

I am of two minds as to whether or not to backport the patch or to close the
PRs as resolved.

Thoughts?

Paul

[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sat, Jul 15, 2023 at 06:15:44AM +0000, pault at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139
> 
> --- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> ---
> (In reply to anlauf from comment #7)
> > Updating known-to-work/known to fail version.
> > 
> > Paul/Steve: do you want to assign this PR to one of you?
> 
> I am of two minds as to whether or not to backport the patch or to close the
> PRs as resolved.
> 
> Thoughts?
> 

Is this patch a "side-effect" of your larger attack on ASSOCIATE
bugs?  If it's independent of that effort, I see no reason to
backport.