[Bug fortran/104573] New: ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[Bug fortran/104573] New: ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[gscfq@t-online.de]

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

            Bug ID: 104573
           Summary: ICE in resolve_structure_cons, at
                    fortran/resolve.cc:1299
           Product: gcc
           Version: 12.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 :
(gcc configured with --enable-checking=yes)


$ cat z1.f90
program p
   type t
   end type
   type(*), parameter :: x = t()
   print *, x
end


$ cat z2.f90
program p
   type t
      integer :: n
   end type
   type(*), parameter :: x = t(1)
   print *, x
end


$ gfortran-12-20220213 -c z1.f90
z1.f90:4:26:

    4 |    type(*), parameter :: x = t()
      |                          1
Error: Assumed type of variable x at (1) is only permitted for dummy variables
z1.f90:4:28:

    4 |    type(*), parameter :: x = t()
      |                            1
Error: Cannot convert TYPE(t) to TYPE(*) at (1)
f951: internal compiler error: Segmentation fault
0xe7073f crash_signal
        ../../gcc/toplev.cc:322
0x7b30e4 resolve_structure_cons
        ../../gcc/fortran/resolve.cc:1299
0x7a0c91 gfc_resolve_expr(gfc_expr*)
        ../../gcc/fortran/resolve.cc:7228
0x7a9324 gfc_resolve_expr(gfc_expr*)
        ../../gcc/fortran/resolve.cc:7136
0x7a9324 gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.cc:11927
0x7a7cdf gfc_resolve_blocks(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.cc:10943
0x7a8038 gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.cc:11917
0x7aa977 resolve_codes
        ../../gcc/fortran/resolve.cc:17536
0x7aaa3e gfc_resolve(gfc_namespace*)
        ../../gcc/fortran/resolve.cc:17571
0x792d64 resolve_all_program_units
        ../../gcc/fortran/parse.cc:6586
0x792d64 gfc_parse_file()
        ../../gcc/fortran/parse.cc:6842
0x7e102f gfc_be_parse_file
        ../../gcc/fortran/f95-lang.cc:216

[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Only want to access the components of a derived type if we have an actual
derived type.

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 835a4783718..ef274e05d4a 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -1296,7 +1296,7 @@ resolve_structure_cons (gfc_expr *expr, int init)
   if (expr->ref)
     comp = expr->ref->u.c.sym->components;
   else
-    comp = expr->ts.u.derived->components;
+    comp = expr->ts.type == BT_DERIVED ? expr->ts.u.derived->components :
NULL;

   for (; comp && cons; comp = comp->next, cons = gfc_constructor_next (cons))
     {

[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Only want to access the components of a derived type if we have an actual
> derived type.

I was wondering if we also need to allow BT_CLASS.
So something like the following might also work:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 266e41e25b1..2fa1acdbd6d 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -1288,15 +1288,17 @@ resolve_structure_cons (gfc_expr *expr, int init)
        }
     }

-  cons = gfc_constructor_first (expr->value.constructor);
-
   /* A constructor may have references if it is the result of substituting a
      parameter variable.  In this case we just pull out the component we
      want.  */
   if (expr->ref)
     comp = expr->ref->u.c.sym->components;
-  else
+  else if (expr->ts.u.derived)
     comp = expr->ts.u.derived->components;
+  else
+    return false;
+
+  cons = gfc_constructor_first (expr->value.constructor);

   for (; comp && cons; comp = comp->next, cons = gfc_constructor_next (cons))
     {

[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Feb 16, 2022 at 08:10:34PM +0000, anlauf at gcc dot gnu.org wrote:
> 
> I was wondering if we also need to allow BT_CLASS.

I'm not sure.  I don't use CLASSes, so only know a bit
about them.  If I check F18:7.5.6, I find

C786  (R753) A final-subroutine-name shall be the name of a moduler
   procedure with exactly one dummy argument. That argument shall
   be nonoptional and shall be a noncoarray, nonpointer, nonallocatable,
   *** nonpolymorphic ***
   variable of the derived type being defined. All length type
   parameters of the dummy argument shall be assumed. The dummy
   argument shall not have the INTENT (OUT) or VALUE attribute.

Does the highlighted "*** nonpolymorphic ***" eliminate
CLASS?

> So something like the following might also work:
> 
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 266e41e25b1..2fa1acdbd6d 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -1288,15 +1288,17 @@ resolve_structure_cons (gfc_expr *expr, int init)
>         }
>      }
> 
> -  cons = gfc_constructor_first (expr->value.constructor);
> -
>    /* A constructor may have references if it is the result of substituting a
>       parameter variable.  In this case we just pull out the component we
>       want.  */
>    if (expr->ref)
>      comp = expr->ref->u.c.sym->components;
> -  else
> +  else if (expr->ts.u.derived)
>      comp = expr->ts.u.derived->components;
> +  else
> +    return false;
> +
> +  cons = gfc_constructor_first (expr->value.constructor);
> 
>    for (; comp && cons; comp = comp->next, cons = gfc_constructor_next (cons))
>      {

Your patch looks cleaner than mine.  Once we decide on whether
CLASS can occur and if yours regression tests okay, then I 
think you can commit.  It's fairly obvious patch.

[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #3)
> I'm not sure.  I don't use CLASSes, so only know a bit
> about them.  If I check F18:7.5.6, I find
> 
> C786  (R753) A final-subroutine-name shall be the name of a moduler
>    procedure with exactly one dummy argument. That argument shall
>    be nonoptional and shall be a noncoarray, nonpointer, nonallocatable,
>    *** nonpolymorphic ***
>    variable of the derived type being defined. All length type
>    parameters of the dummy argument shall be assumed. The dummy
>    argument shall not have the INTENT (OUT) or VALUE attribute.

Steve, there's no finalization referred to in this PR.
Can you please recheck?

[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Feb 16, 2022 at 08:32:25PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573
> 
> --- Comment #4 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #3)
> > I'm not sure.  I don't use CLASSes, so only know a bit
> > about them.  If I check F18:7.5.6, I find
> > 
> > C786  (R753) A final-subroutine-name shall be the name of a moduler
> >    procedure with exactly one dummy argument. That argument shall
> >    be nonoptional and shall be a noncoarray, nonpointer, nonallocatable,
> >    *** nonpolymorphic ***
> >    variable of the derived type being defined. All length type
> >    parameters of the dummy argument shall be assumed. The dummy
> >    argument shall not have the INTENT (OUT) or VALUE attribute.
> 
> Steve, there's no finalization referred to in this PR.
> Can you please recheck?
> 

Ah dang.  I conflated PR 104572, to which I just posted a patch,
with this PR.  Your patch is then likely the correct approach.
Sorry about any confusion.

[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
The patch in comment#2 regtests ok.

I've been thinking a little to find cases where there should be a difference
to the patch in comment#1, but did not succeed so far.  At least not with
minor variations of the original testcases.

[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #7 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-February/057554.html

[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:12463f1ecbcb30b39b8212454a6e598645123305

commit r12-7456-g12463f1ecbcb30b39b8212454a6e598645123305
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Tue Mar 1 23:13:17 2022 +0100

    Fortran: error recovery after invalid assumed type declaration

    gcc/fortran/ChangeLog:

            PR fortran/104573
            * resolve.cc (resolve_structure_cons): Avoid NULL pointer
            dereference when there is no valid component.

    gcc/testsuite/ChangeLog:

            PR fortran/104573
            * gfortran.dg/assumed_type_14.f90: New test.

[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |12.0

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed for gcc-12.  Closing.

Thanks for the report!