[Bug fortran/104625] New: ICE in fixup_array_ref, at fortran/resolve.cc:9275

[Bug fortran/104625] New: ICE in fixup_array_ref, at fortran/resolve.cc:9275

[gscfq@t-online.de]

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

            Bug ID: 104625
           Summary: ICE in fixup_array_ref, at fortran/resolve.cc:9275
           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: ---

Started with r10, changed between 20190825 and 20190901 :
(in addition to pr104555)


$ cat z1.f90
program p
   type t
      integer :: a
   end type
contains
   subroutine s(x)
      class(t) :: x(..)
      select rank (y => x)
      rank (1)
         select type (z => (y))
         type is (t)
         end select
      end select
   end
end


$ gfortran-12-20220220 -c z1.f90
f951: internal compiler error: Segmentation fault
0xcc909f crash_signal
        ../../gcc/toplev.cc:322
0x75b75a fixup_array_ref
        ../../gcc/fortran/resolve.cc:9275
0x773e24 resolve_select_type
        ../../gcc/fortran/resolve.cc:9530
0x768f13 gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.cc:12173
0x76af77 resolve_codes
        ../../gcc/fortran/resolve.cc:17536
0x76b03e gfc_resolve(gfc_namespace*)
        ../../gcc/fortran/resolve.cc:17571
0x769089 gfc_resolve(gfc_namespace*)
        ../../gcc/fortran/resolve.cc:17556
0x769089 resolve_block_construct
        ../../gcc/fortran/resolve.cc:10791
0x769089 gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.cc:12181
0x7682df gfc_resolve_blocks(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.cc:10943
0x76a2cf resolve_select_rank
        ../../gcc/fortran/resolve.cc:9953
0x76a2cf gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.cc:12177
0x76af77 resolve_codes
        ../../gcc/fortran/resolve.cc:17536
0x76aeae resolve_codes
        ../../gcc/fortran/resolve.cc:17519
0x76b03e gfc_resolve(gfc_namespace*)
        ../../gcc/fortran/resolve.cc:17571
0x753364 resolve_all_program_units
        ../../gcc/fortran/parse.cc:6586
0x753364 gfc_parse_file()
        ../../gcc/fortran/parse.cc:6842
0x7a0a5f gfc_be_parse_file
        ../../gcc/fortran/f95-lang.cc:216

[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275

[gscfq@t-online.de]

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

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

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

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

For comparison :


$ cat z2.f90
program p
   type t
      integer :: a
   end type
contains
   subroutine s(x)
      class(t) :: x(..)
      select rank (y => x)
      rank (1)
         select type (z => y)
         type is (t)
         end select
      end select
   end
end


$ gfortran-12-20220220 -c z2.f90
$

[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE in fixup_array_ref, at  |ICE in fixup_array_ref, at
                   |fortran/resolve.cc:9275     |fortran/resolve.cc:9275
                   |                            |since
                   |                            |r10-2912-g70570ec192745095
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-02-24

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

[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Intel rejects the code with:

pr104625.f90(10): error #8247: Selector in SELECT TYPE statements must be
polymorphic value.
    select type (z => (y))
----^

However, NAG thinks the code is actually valid.  And from reading the
standard, I do not immediately see that the parentheses should be a problem:

F2023 has:

C1162 (R1155) If selector is not a named variable, associate-name => shall
appear.

C1164 (R1155) The selector in a select-type-stmt shall be polymorphic.

F2018 has the same wording (slight shift in actual number of constraint).


For this reason changing to ice-on-valid.

[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org

--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 56192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56192&action=edit
Fix for this PR

This will require careful perusal of the standard to make sure that there are
not other exclusions.

I'm onto it.

Paul

[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #4)
> Created attachment 56192 [details]
> Fix for this PR

I was thinking of something along these lines, but was wondering:

a) there could be multiple nested parentheses, not just one.  (-> while loop?)

b) I think the associate name cannot be used in a variable definition
   context if the selector is a temporary (i.e. parenthesized)

> This will require careful perusal of the standard to make sure that there
> are not other exclusions.

Besides (b)?

> I'm onto it.

This is great.

FYI: a further reduced testcase:

program p
  implicit none
  type t
     integer :: a
  end type
contains
  subroutine s(x)
!   class(t) :: x          ! OK
    class(t) :: x(:)       ! ICE in combination with below

    select type (y =>  x)  ! OK
    type is (t)
    end select
    select type (z => (x)) ! ICE
    type is (t)
    end select
    select type (u => ((x))) ! ICE
    type is (t)
    end select
  end
end

[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Steve Lionel of Intel confirmed that the code is valid, and that if X is
polymorphic, so is (X):

community.intel.com/t5/Intel-Fortran-Compiler/SELECT-TYPE-statement-and-parenthesized-selector/m-p/1537256#M168843

[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to anlauf from comment #6)
> Steve Lionel of Intel confirmed that the code is valid, and that if X is
> polymorphic, so is (X):
> 
> community.intel.com/t5/Intel-Fortran-Compiler/SELECT-TYPE-statement-and-
> parenthesized-selector/m-p/1537256#M168843

Indeed:

"R1105: selector is expr or variable" is totally unambiguous.

I will post the latest version of the patch at end-of-play today. I have dealt
with nested parentheses but find that array references to 'z' in the original
testcase are generating "unclassifiable statement" errors.

I have also corrected the error message generated when 'z' is put in an
assignment context from, "‘z’ at (1) associated to vector-indexed target cannot
be used in a variable definition context (assignment)" to "‘z’ at (1)
associated to expression cannot be used in a variable definition context
(assignment)", simply by checking for vector-indexing at expr.cc:6477.

Cheers

Paul

[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to anlauf from comment #6)
> Steve Lionel of Intel confirmed that the code is valid, and that if X is
> polymorphic, so is (X):
> 
> community.intel.com/t5/Intel-Fortran-Compiler/SELECT-TYPE-statement-and-
> parenthesized-selector/m-p/1537256#M168843

Indeed:

"R1105: selector is expr or variable" is totally unambiguous.

I will post the latest version of the patch at end-of-play today. I have dealt
with nested parentheses but find that array references to 'z' in the original
testcase are generating "unclassifiable statement" errors.

I have also corrected the error message generated when 'z' is put in an
assignment context from, "‘z’ at (1) associated to vector-indexed target cannot
be used in a variable definition context (assignment)" to "‘z’ at (1)
associated to expression cannot be used in a variable definition context
(assignment)", simply by checking for vector-indexing at expr.cc:6477.

Cheers

Paul

[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 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:b038e202210eb3e982c2ec802438edd523b47a02

commit r14-4966-gb038e202210eb3e982c2ec802438edd523b47a02
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Fri Oct 27 09:33:38 2023 +0100

    Fortran: Fix some problems with SELECT TYPE selectors [PR104625].

    2023-10-27  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/104625
            * expr.cc (gfc_check_vardef_context): Check that the target
            does have a vector index before emitting the specific error.
            * match.cc (copy_ts_from_selector_to_associate): Ensure that
            class valued operator expressions set the selector rank and
            use the rank to provide the associate variable with an
            appropriate array spec.
            * resolve.cc (resolve_operator): Reduce stacked parentheses to
            a single pair.
            (fixup_array_ref): Extract selector symbol from parentheses.

    gcc/testsuite/
            PR fortran/104625
            * gfortran.dg/pr104625.f90: New test.
            * gfortran.dg/associate_55.f90: Change error check.

[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #10 from Paul Thomas <pault at gcc dot gnu.org> ---
Fixed on mainline. If there is any demand, I can back port it after a few
weeks. However, I will close it now.

Thanks once again, Gerhard!

Paul