[Bug fortran/106771] New: [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

[Bug fortran/106771] New: [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

[federico.perini at gmail dot com]

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

            Bug ID: 106771
           Summary: [OOP] ICE with PACK intrinsic, in
                    gfc_conv_expr_descriptor, at
                    fortran/trans-array.c:7328
           Product: gcc
           Version: 9.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: federico.perini at gmail dot com
  Target Milestone: ---

I'm getting an ICE using the PACK intrinsic from within a polymorphic entity.
There are several similar bugs reported, but none seems to address PACK, so I'm
opening a new ticket. BTW: I've tested it on godbolt (try here:
https://godbolt.org/z/cnj6PzqKz)
And it looks like: 

WORKS on: 10.4.0, 11 (all), 12 (all)
ICE   on: 4.9, 5-8 (all), 9 (all), 10.1, 10.2, 10.3

The mask is created from a polymorphic elemental function on the object
Here's a minimal example: 

module test
    implicit none

    type::t
       integer, allocatable :: iloc(:)
       contains 
          procedure :: is_active => isa
          procedure :: list2loc => myfun_poly
    end type t

    contains

    elemental logical function isa(this,i)
       class(t), intent(in) :: this
       integer, intent(in) :: i
       if (i>0 .and. i<=merge(size(this%iloc),0,allocated(this%iloc))) then 
          isa = this%iloc(i)>0
       else
          isa = .false.
       endif  
    end function isa

    ! internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:7328
    function myfun_poly(this,IDs) result (ilocs)
        class(t), intent(in) :: this
        integer, intent(in) :: IDs(:)
        integer, allocatable :: ilocs(:)
        if (size(IDs)<=0) then
           allocate(ilocs(0))
        else
           ilocs = pack(this%iloc(IDs),this%is_active(ilocs))
        endif
    end function myfun_poly

    ! WORKS
    function myfun(this,IDs) result (ilocs)
        type(t), intent(in) :: this
        integer, intent(in) :: IDs(:)
        integer, allocatable :: ilocs(:)
        if (size(IDs)<=0) then
           allocate(ilocs(0))
        else
           ilocs = pack(this%iloc(IDs),this%is_active(ilocs))
        endif
    end function myfun
end module test    

program testp
   use test
   implicit none

   type(t) :: a

   integer :: rnd(100)
   real :: x(100)
   integer, allocatable :: list(:)

   call random_number(x); rnd = ceiling(x*100)

   ! Works
   list = myfun(a,rnd)
   ! ICE
   list = a%list2loc(rnd)

   print *, 'list=',list

end program testp


Hope this helps,
federico

[Bug fortran/106771] [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org
      Known to fail|                            |8.5.0
      Known to work|                            |10.4.0, 11.3.0, 12.2.0,
                   |                            |9.5.0
   Last reconfirmed|                            |2022-08-29
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
           Keywords|                            |ice-on-valid-code

--- Comment #1 from anlauf at gcc dot gnu.org ---
Funny.  Replacing

       ilocs = pack(this%iloc(IDs),this%is_active(ilocs))

by

       ilocs = pack(this%iloc(IDs),[this%is_active(ilocs)])

seems to be a workaround for gcc-8 - at least as far as the ICE is concerned.
(The testcase crashes at runtime with any compiler I tried, so I guess
it was reduced too much for this.)

I don't see any issues on mainline, even when running under valgrind,
so I guess the issue was fixed.

Does anybody want to do a bisection to find the commit which fixed it?

[Bug fortran/106771] [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Playing a little, I found that the issue might be related to the elemental
function isa.

The following dumb replacement

  function isa(this,i)
    class(t), intent(in) :: this
    integer,  intent(in) :: i(:)
    logical              :: isa(size(i))
    integer :: j
    do j = 1, size(i)
       if (i(j)>0 .and. i(j)<=merge(size(this%iloc),0,allocated(this%iloc)))
then
          isa(j) = this%iloc(i(j))>0
       else
          isa(j) = .false.
       end if
    end do
  end function isa

also avoids the ICE.

[Bug fortran/106771] [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

[federico.perini at gmail dot com]

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

--- Comment #3 from federico <federico.perini at gmail dot com> ---
Right: here is a version where the object is initialized: 

https://godbolt.org/z/o566cPG8P

I also see that for the versions that compile (e.g., 11.1.0), there's a weird
SEGFAULT error at this line: 


    elemental logical function isa(this,i)
       class(t), intent(in) :: this
       integer, intent(in) :: i
       integer :: n
       n = merge(size(this%iloc),0,allocated(this%iloc))
       if (i>0 .and. i<=n) then ! Segmentation fault here 
          isa = this%iloc(i)>0
       else
          isa = .false.
       endif  
    end function isa

So it at least compiles, but apparently the bug is hidden somewhere else?

[Bug fortran/106771] [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to federico from comment #3)
> Right: here is a version where the object is initialized: 
> 
> https://godbolt.org/z/o566cPG8P
> 
> I also see that for the versions that compile (e.g., 11.1.0), there's a
> weird SEGFAULT error at this line: 
> 
> 
>     elemental logical function isa(this,i)
>        class(t), intent(in) :: this
>        integer, intent(in) :: i
>        integer :: n
>        n = merge(size(this%iloc),0,allocated(this%iloc))
>        if (i>0 .and. i<=n) then ! Segmentation fault here 
>           isa = this%iloc(i)>0
>        else
>           isa = .false.
>        endif  
>     end function isa
> 
> So it at least compiles, but apparently the bug is hidden somewhere else?

Well, the following might be the reason for failure:

       ilocs = pack(this%iloc(IDs),this%is_active(ilocs))

Here ilocs is not allocated, it is the function result.

Also Intel does not like it.

Replacing these lines with

       ilocs = pack(this%iloc(IDs),this%is_active(IDs))

makes the code run successfully for gcc versions listed under "known to work".

User error?

[Bug fortran/106771] [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

[federico.perini at gmail dot com]

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

--- Comment #5 from federico <federico.perini at gmail dot com> ---
My bad, the SEGFAULT is my mistake, I've made a half-baked example that does
not work. Here's the fixed one: 

module test
    implicit none

    type::t
       integer, allocatable :: iloc(:)
       contains 
          procedure :: is_active => isa
          procedure :: list2loc => myfun_poly
    end type t

    contains

    elemental logical function isa(this,i)
       class(t), intent(in) :: this
       integer, intent(in) :: i
       integer :: n
       n = merge(size(this%iloc),0,allocated(this%iloc))
       if (i>0 .and. i<=n) then ! Segmentation fault here 
          isa = this%iloc(i)>0
       else
          isa = .false.
       endif  
    end function isa

    ! internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:7328
    function myfun_poly(this,IDs) result (ilocs)
        class(t), intent(in) :: this
        integer, intent(in) :: IDs(:)
        integer, allocatable :: ilocs(:)
        if (size(IDs)<=0) then
           allocate(ilocs(0))
        else
           ilocs = pack(this%iloc(IDs),this%is_active(IDs))
        endif
    end function myfun_poly

    ! WORKS
    function myfun(this,IDs) result (ilocs)
        type(t), intent(in) :: this
        integer, intent(in) :: IDs(:)
        integer, allocatable :: ilocs(:)
        if (size(IDs)<=0) then
           allocate(ilocs(0))
        else
           ilocs = pack(this%iloc(IDs),this%is_active(IDs))
        endif
    end function myfun
end module test    

program testp
   use test
   implicit none

   type(t) :: a

   integer :: rnd(100),i
   real :: x(100)
   integer, allocatable :: list(:)

   ! Create a dummy initialization
   a%iloc = [(i,i=1,100)]

   call random_number(x); rnd = ceiling(x*99)

   ! Works
   print *, 'rnd=',rnd
   list = myfun(a,rnd)
   ! ICE
   list = a%list2loc(rnd)

   print *, 'list=',list

end program testp

The segfault is now gone, but the ICE remains for all versions until 10.3.0
(see https://godbolt.org/z/6TKa4sEe9)

[Bug fortran/106771] [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note that the GCC 9 branch is no longer maintained so the issue is fixed in all
maintained versions?  If so please close as fixed.

[Bug fortran/106771] [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED
      Known to work|                            |11.2.0

--- Comment #7 from anlauf at gcc dot gnu.org ---
The example in comment#5 also works for me with the listed "known to work".
Please switch to using one of those or newer.

Closing as fixed.