[Bug fortran/95398] New: ICE on invalid code

[Bug fortran/95398] New: ICE on invalid code

[kargl at gcc dot gnu.org]

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

            Bug ID: 95398
           Summary: ICE on invalid code
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Code posted at 

https://groups.google.com/forum/#!topic/comp.lang.fortran/mW1gV6tyxXk

leads to

% gfcx -c a.f90
a.f90:32:16:

   32 |          foo => array1(2,U)
      |                1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
a.f90:34:16:

   34 |          foo => array2(2,U)
      |                1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
f951: internal compiler error: Segmentation fault
0xdf6e3a crash_signal
        ../../gccx/gcc/toplev.c:328
0x83fb5c resolve_select_type
        ../../gccx/gcc/fortran/resolve.c:9169
0x83c9a4 gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gccx/gcc/fortran/resolve.c:11908
0x840f78 resolve_codes
        ../../gccx/gcc/fortran/resolve.c:17197
0x82ba33 gfc_resolve(gfc_namespace*)
        ../../gccx/gcc/fortran/resolve.c:17232
0x82ba33 gfc_resolve(gfc_namespace*)
        ../../gccx/gcc/fortran/resolve.c:17211
0x81de68 resolve_all_program_units
        ../../gccx/gcc/fortran/parse.c:6241
0x81de68 gfc_parse_file()
        ../../gccx/gcc/fortran/parse.c:6488
0x871858 gfc_be_parse_file
        ../../gccx/gcc/fortran/f95-lang.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

This patch fixes the ICE. Do with it what you want.


Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c       (revision 280157)
+++ gcc/fortran/resolve.c       (working copy)
s@@ -9166,7 +9172,9 @@ resolve_select_type (gfc_code *code, gfc_namespace *ol
          selector_type = CLASS_DATA (code->expr2)->ts.u.derived;
        }

-      if (code->expr2->rank && CLASS_DATA (code->expr1)->as)
+      if (code->expr2->rank
+         && code->expr1->ts.type == BT_CLASS
+         && CLASS_DATA (code->expr1)->as)
        CLASS_DATA (code->expr1)->as->rank = code->expr2->rank;

       /* F2008: C803 The selector expression must not be coindexed.  */

[Bug fortran/95398] ICE on invalid code

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #1 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, May 28, 2020 at 09:33:08PM +0000, kargl at gcc dot gnu.org wrote:
> 
> Code posted at 
> 
> https://groups.google.com/forum/#!topic/comp.lang.fortran/mW1gV6tyxXk

Here's the code

   implicit none

   type :: t1
     integer :: i
   end type

   type, extends(t1) :: t2
   end type

   class(t1), allocatable :: array1(:,:)
   class(t2), allocatable :: array2(:,:)

   allocate(array1(3,3))
   allocate(array2(3,3))

   select type(b => foo(1))
      type is (t1)
         b%i = 1 !VDC
      type is (t2)
         call sub_with_in_and_inout_param(b,b) !VDC
   end select

   contains

     function foo(i)
       integer :: U(2)
       integer :: i
       class(t1), POINTER :: foo(:)
       ALLOCATE(FOO(2))
       U = (/ 1,2 /)
       if (i>0) then
         foo => array1(2,U)
       else
         foo => array2(2,U)
       end if
     end function

     subroutine sub_with_in_and_inout_param(y, z)
        type(t2), INTENT(IN) :: y(:)
        class(t2), INTENT(INOUT) :: z(:)
        z%i = 10
     end subroutine

end

[Bug fortran/95398] ICE on invalid code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-06-04

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed. GCC5 gives

pr95398.f90:32:16:

          foo => array1(2,U)
                1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
pr95398.f90:34:16:

          foo => array2(2,U)
                1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
pr95398.f90:18:9:

          b%i = 1 !VDC
         1
Error: 'b' at (1) associated to expression can not be used in a variable
definition context (assignment)
pr95398.f90:20:42:

          call sub_with_in_and_inout_param(b,b) !VDC
                                          1
Error: Rank mismatch in argument 'y' at (1) (rank-1 and scalar)

So this may be a regression.

[Bug fortran/95398] ICE on invalid code

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mark Eggleston
<markeggleston@gcc.gnu.org>:

https://gcc.gnu.org/g:3d137b75febd1a4ad70bcc64e0f79198f5571b86

commit r11-2964-g3d137b75febd1a4ad70bcc64e0f79198f5571b86
Author: Mark Eggleston <markeggleston@gcc.gnu.org>
Date:   Mon Jun 1 08:15:31 2020 +0100

    Fortran  : ICE on invalid code PR95398

    The CLASS_DATA macro is used to shorten the code accessing the derived
    components of an expressions type specification.  If the type is not
    BT_CLASS the derived pointer is NULL resulting in an ICE.  To avoid
    dereferencing a NULL pointer the type should be BT_CLASS.

    2020-09-01  Steven G. Kargl  <kargl@gcc.gnu.org>

    gcc/fortran

            PR fortran/95398
            * resolve.c (resolve_select_type): Add check for BT_CLASS
            type before using the CLASS_DATA macro which will have a
            NULL pointer to derive components if it isn't BT_CLASS.

    2020-09-01  Mark Eggleston  <markeggleston@gcc.gnu.org>

    gcc/testsuite

            PR fortran/95398
            * gfortran.dg/pr95398.f90: New test.

[Bug fortran/95398] ICE on invalid code

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Mark Eggleston
<markeggleston@gcc.gnu.org>:

https://gcc.gnu.org/g:84b14e9cd4e05c926a75e8e97ee57dbd3350e752

commit r10-8697-g84b14e9cd4e05c926a75e8e97ee57dbd3350e752
Author: Mark Eggleston <markeggleston@gcc.gnu.org>
Date:   Mon Jun 1 08:15:31 2020 +0100

    Fortran  : ICE on invalid code PR95398

    The CLASS_DATA macro is used to shorten the code accessing the derived
    components of an expressions type specification.  If the type is not
    BT_CLASS the derived pointer is NULL resulting in an ICE.  To avoid
    dereferencing a NULL pointer the type should be BT_CLASS.

    2020-09-01  Steven G. Kargl  <kargl@gcc.gnu.org>

    gcc/fortran

            PR fortran/95398
            * resolve.c (resolve_select_type): Add check for BT_CLASS
            type before using the CLASS_DATA macro which will have a
            NULL pointer to derive components if it isn't BT_CLASS.

    2020-09-01  Mark Eggleston  <markeggleston@gcc.gnu.org>

    gcc/testsuite

            PR fortran/95398
            * gfortran.dg/pr95398.f90: New test.

    (cherry picked from commit 3d137b75febd1a4ad70bcc64e0f79198f5571b86)

[Bug fortran/95398] ICE on invalid code

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markeggleston at gcc dot gnu.org
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #5 from markeggleston at gcc dot gnu.org ---
Committed to master and backported to gcc-10.

[Bug fortran/95398] ICE on invalid code

[cvs-commit at gcc dot gnu.org]

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

--- 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:577223aebc7acdd31e62b33c1682fe54a622ae27

commit r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Wed Jun 21 17:05:58 2023 +0100

    Fortran: Fix some bugs in associate [PR87477]

    2023-06-21  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/87477
            PR fortran/88688
            PR fortran/94380
            PR fortran/107900
            PR fortran/110224
            * decl.cc (char_len_param_value): Fix memory leak.
            (resolve_block_construct): Remove unnecessary static decls.
            * expr.cc (gfc_is_ptr_fcn): New function.
            (gfc_check_vardef_context): Use it to permit pointer function
            result selectors to be used for associate names in variable
            definition context.
            * gfortran.h: Prototype for gfc_is_ptr_fcn.
            * match.cc (build_associate_name): New function.
            (gfc_match_select_type): Use the new function to replace inline
            version and to build a new associate name for the case where
            the supplied associate name is already used for that purpose.
            * resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
            associate names with pointer function targets to be used in
            variable definition context.
            * trans-decl.cc (gfc_get_symbol_decl): Unlimited polymorphic
            variables need deferred initialisation of the vptr.
            (gfc_trans_deferred_vars): Do the vptr initialisation.
            * trans-stmt.cc (trans_associate_var): Ensure that a pointer
            associate name points to the target of the selector and not
            the selector itself.

    gcc/testsuite/
            PR fortran/87477
            PR fortran/107900
            * gfortran.dg/pr107900.f90 : New test

            PR fortran/110224
            * gfortran.dg/pr110224.f90 : New test

            PR fortran/88688
            * gfortran.dg/pr88688.f90 : New test

            PR fortran/94380
            * gfortran.dg/pr94380.f90 : New test

            PR fortran/95398
            * gfortran.dg/pr95398.f90 : Set -std=f2008, bump the line
            numbers in the error tests by two and change the text in two.