[Bug fortran/99138] New: ICE in gfc_match_rvalue, at fortran/primary.c:3738

[Bug fortran/99138] New: ICE in gfc_match_rvalue, at fortran/primary.c:3738

[gscfq@t-online.de]

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

            Bug ID: 99138
           Summary: ICE in gfc_match_rvalue, at fortran/primary.c:3738
           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: ---

This invalid code affects versions down to r6 :
(print statement in contains section)


$ cat z1.f90
module m
   interface
      module function f(x)
         integer, intent(in) :: x
         class(*), allocatable :: f
      end
   end interface
end
submodule(m) m2
contains
   module function f(x)
      integer, intent(in) :: x
      class(*), allocatable :: f
   end
   print *, f(3)
end


$ gfortran-11-20210214 -c z1.f90
f951: internal compiler error: Segmentation fault
0xc09bcf crash_signal
        ../../gcc/toplev.c:327
0x6ec98e gfc_match_rvalue(gfc_expr**)
        ../../gcc/fortran/primary.c:3738
0x6c0eae match_primary
        ../../gcc/fortran/matchexp.c:157
0x6c0eae match_level_1
        ../../gcc/fortran/matchexp.c:211
0x6c0eae match_mult_operand
        ../../gcc/fortran/matchexp.c:267
0x6c10f8 match_add_operand
        ../../gcc/fortran/matchexp.c:356
0x6c134c match_level_2
        ../../gcc/fortran/matchexp.c:480
0x6c14a2 match_level_3
        ../../gcc/fortran/matchexp.c:551
0x6c1594 match_level_4
        ../../gcc/fortran/matchexp.c:599
0x6c1594 match_and_operand
        ../../gcc/fortran/matchexp.c:693
0x6c1782 match_or_operand
        ../../gcc/fortran/matchexp.c:722
0x6c1852 match_equiv_operand
        ../../gcc/fortran/matchexp.c:765
0x6c1924 match_level_5
        ../../gcc/fortran/matchexp.c:811
0x6c0d01 gfc_match_expr(gfc_expr**)
        ../../gcc/fortran/matchexp.c:870
0x6a8c99 match_io_element
        ../../gcc/fortran/io.c:3661
0x6ab575 match_io_list
        ../../gcc/fortran/io.c:3709
0x6ab974 match_io
        ../../gcc/fortran/io.c:4387
0x6af3fa gfc_match_print()
        ../../gcc/fortran/io.c:4443
0x6dbc21 match_word
        ../../gcc/fortran/parse.c:65
0x6e07a3 decode_statement
        ../../gcc/fortran/parse.c:537

[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-02-18
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r6-1958-g4668d6f9c00d4767.

[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org
           Keywords|                            |ice-on-valid-code

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Confirmed – with 'class(*), allocatable :: f(:)' it should be valid (with prior
assignment).

The problem is in gfc_match_rvalue:

3737          if (sym->ts.type == BT_CLASS && sym->attr.class_ok
3738              && CLASS_DATA (sym)->as)

without submodules, we have:
  sym->ts.u.derived->components->as
which is working (and either NULL in the original example or != NULL with my
modification).

However, with submodules,
  sym->ts.u.derived->components
is NULL, i.e. 'sym->ts.u.derived' (name = "STAR") does not have any
scomponents, but it should have two, _data and _vptr!

[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #2)
> Confirmed – with 'class(*), allocatable :: f(:)' it should be valid (with
> prior assignment).
> 
> The problem is in gfc_match_rvalue:
> 
> 3737          if (sym->ts.type == BT_CLASS && sym->attr.class_ok
> 3738              && CLASS_DATA (sym)->as)
> 
> without submodules, we have:
>   sym->ts.u.derived->components->as
> which is working (and either NULL in the original example or != NULL with my
> modification).
> 
> However, with submodules,
>   sym->ts.u.derived->components
> is NULL, i.e. 'sym->ts.u.derived' (name = "STAR") does not have any
> scomponents, but it should have two, _data and _vptr!

Hi Tobias,

Is the problem not that the parser is not picking up the incorrectly placed
print statement? It should never be passed to the matcher because it is in the
contains context.

It also should said that it has everything to do with module procedures and
nothing to do with submodules. This has the same error sequence:

module m
   interface
      module function f(x)
         integer, intent(in) :: x
         class(*), allocatable :: f
      end
   end interface
contains
   module function f(x)
      integer, intent(in) :: x
      class(*), allocatable :: f
   end function
   print *, f(3)
end

I suspect that the end function is not popping the level.

Cheers

Paul

[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Paul Thomas from comment #3)
> Is the problem not that the parser is not picking up the incorrectly placed
> print statement? It should never be passed to the matcher because it is in
> the contains context.

Ups. I mess up my visual parser ... – Yes, I concur that rvalue matching should
not happen (only some 'end' – or 'subroutine'/'[type-spec|(im)pure|...]
function' is permitted – unless it is 'type; ...; contains' which has some
other permitted values or ...

The current code has:

parse_contained()
   st = next_statement ();
      switch (st)
        {
        case ST_NONE:
        case ST_FUNCTION:
        case ST_SUBROUTINE:
        case ST_END_FUNCTION:
        case ST_END_MODULE:
        case ST_END_SUBMODULE:
        case ST_END_PROGRAM:
        case ST_END_SUBROUTINE:
           ...
        default:
          gfc_error ("Unexpected %s statement in CONTAINS section at %C",
                     gfc_ascii_statement (st));

It sounds as if you want to have something which only tries to match those –
and then simply stops with an error at the the end, pointing to the line
without trying to parse it. — That would avoid a lot of 'gfc_error' which are
silenced and speeds up parsing (not that it is really the bottle neck).

[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The following fails the same way:

module m
   interface
      module function f()
         class(*), allocatable :: f(:)
      end
   end interface
contains
   module function f(x)
         class(*), allocatable :: f(:)
   end function
end

Except that the fail is now in resolve.c, but again when accessing
'CLASS_DATA (sym)->'.

[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
The following patch fixes several NULL pointer dereferences exhibited by the
testcases in comment#0 and comment#5:

diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index a6df885c80c..153e9037127 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -3714,7 +3714,7 @@ gfc_match_rvalue (gfc_expr **result)
       e->where = gfc_current_locus;

       if (sym->ts.type == BT_CLASS && sym->attr.class_ok
-         && CLASS_DATA (sym)->as)
+         && CLASS_DATA (sym) && CLASS_DATA (sym)->as)
        e->rank = CLASS_DATA (sym)->as->rank;
       else if (sym->as != NULL)
        e->rank = sym->as->rank;
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 32015c21efc..59870bbd502 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8902,6 +8902,8 @@ resolve_select (gfc_code *code, bool select_type)
 bool
 gfc_type_is_extensible (gfc_symbol *sym)
 {
+  if (sym == NULL)
+    return false;
   return !(sym->attr.is_bind_c || sym->attr.sequence
           || (sym->attr.is_class
               && sym->components->ts.u.derived->attr.unlimited_polymorphic));
@@ -12747,6 +12749,7 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag)
          && sym->ts.u.derived
          && !sym->attr.select_type_temporary
          && !UNLIMITED_POLY (sym)
+         && CLASS_DATA (sym)
          && !gfc_type_is_extensible (CLASS_DATA (sym)->ts.u.derived))
        {
          gfc_error ("Type %qs of CLASS variable %qs at %L is not extensible",
@@ -15432,7 +15435,8 @@ resolve_symbol (gfc_symbol *sym)
       specification_expr = saved_specification_expr;
     }

-  if (sym->ts.type == BT_CLASS && sym->attr.class_ok && sym->ts.u.derived)
+  if (sym->ts.type == BT_CLASS && sym->attr.class_ok && sym->ts.u.derived
+      && CLASS_DATA (sym))
     {
       as = CLASS_DATA (sym)->as;
       class_attr = CLASS_DATA (sym)->attr;

[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738

[anlauf at gcc dot gnu.org]

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
The patch in comment#6 generates an unexpected error:

pr99138.f90:11:2:

   11 |   module function f(x)
      |  1
Error: Type mismatch in function result (CLASS(STAR)/CLASS(*)) between the
MODULE PROCEDURE declaration in MODULE 'm' and the declaration at (1) in
(SUB)MODULE 'm2'

Replacing the module function part with

  module procedure f
  end

makes the code compile, so I think this is an independent issue... :-(

[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
The check in interface.c:gfc_check_result_characteristics has an asymmetry
coming from symbol.c:gfc_type_compatible that could be evaded by swapping
arguments:

diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index f7ca52e6550..8758f146d57 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -1561,7 +1561,7 @@ gfc_check_result_characteristics (gfc_symbol *s1,
gfc_symbol *s2,
     return true;

   /* Check type and rank.  */
-  if (!compare_type_characteristics (r1, r2))
+  if (!compare_type_characteristics (r2, r1))
     {
       snprintf (errmsg, err_len, "Type mismatch in function result (%s/%s)",
                gfc_typename (&r1->ts), gfc_typename (&r2->ts));

However, we then hits other issues later on with the ALLOCATABLE attribute.

:-(