[Bug fortran/113845] New: ice in gfc_get_array_ss

[Bug fortran/113845] New: ice in gfc_get_array_ss

[dcb314 at hotmail dot com]

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

            Bug ID: 113845
           Summary: ice in gfc_get_array_ss
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57368&action=edit
F90 source code

From the flang test suite at
https://github.com/llvm/llvm-project/tree/main/flang/test, file
./Lower/HLFIR/elemental-intrinsics.f90 does this with recent gfortran:

test $ ~/gcc/results.20240208.asan.ubsan/bin/gfortran -c -O1
./Lower/HLFIR/elemental-intrinsics.f90 
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
test $ 

gdb on f951 says:

#0  0x000000000228f236 in xcalloc (nelem=1, elsize=696)
    at ../../trunk.20210101/libiberty/xmalloc.c:158
#1  0x00000000008588ec in gfc_get_array_ss (
    next=0x3221ae8 <gfc_ss_terminator_var>, expr=0x9423af0, dimen=1, 
    type=GFC_SS_SECTION) at ../../trunk.20210101/gcc/fortran/trans-array.cc:724
#2  gfc_walk_array_ref (ss=0x3221ae8 <gfc_ss_terminator_var>, expr=0x9423af0, 
    ref=0x9423c20) at ../../trunk.20210101/gcc/fortran/trans-array.cc:11750
#3  0x0000000000858cd8 in gfc_walk_elemental_function_args (
    ss=0x3221ae8 <gfc_ss_terminator_var>, arg=0x9423a90, 
    intrinsic_sym=0x7ffff7a66610, type=<optimized out>)
    at ../../trunk.20210101/gcc/fortran/trans-array.cc:12015

[Bug fortran/113845] ice in gfc_get_array_ss

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-02-09
     Ever confirmed|0                           |1
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Thanks.  Reduce test case.

subroutine test_adjustl(x)
  character(*) :: x(100)
  call bar(adjustl(x))
end subroutine

subroutine test_adjustr(x)
  character(*) :: x(100)
  call bar(adjustr(x))
end subroutine

On FreeBSD either subroutine causes

% gfcx -c rt.f90
pid 50109 comm f951 has trashed its stack, killing
gfortran: internal compiler error: Illegal instruction signal terminated
program f951
Please submit a full bug report, with preprocessed source (by using
-freport-bug

Note, I have 
% limits | grep stack
  stacksize              524288 kB

[Bug fortran/113845] ice in gfc_get_array_ss

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Thanks.  Reduce test case.
> 
> subroutine test_adjustl(x)
>   character(*) :: x(100)
>   call bar(adjustl(x))
> end subroutine

Forcing gfc_simplify_adjustl to return NULL fixes this issue.
Likely, simplification trashes the stack because ubound is
unknown.

[Bug fortran/113845] ice in gfc_get_array_ss

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> (In reply to kargl from comment #1)
> > Thanks.  Reduce test case.
> > 
> > subroutine test_adjustl(x)
> >   character(*) :: x(100)
> >   call bar(adjustl(x))
> > end subroutine
> 
> Forcing gfc_simplify_adjustl to return NULL fixes this issue.
> Likely, simplification trashes the stack because ubound is
> unknown.

Whoops, after compiling I ran the wrong test code through
gfortran.  This appears to be a red-herring. :(

[Bug fortran/113845] ice in gfc_get_array_ss

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Created attachment 57374
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57374&action=edit
Proof-of-concept patch

The attached - hackish - patch tries to avoid the infinite recursion by
fixing up the character length especially for the intrinsics ADJUST[LR].

I'm not entirely happy with this, but could not yet find a better place.
And in gfc_resolve_adjustl the backend_decl is not yet set.

Suggestions welcome!

[Bug fortran/113845] ice in gfc_get_array_ss

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Feb 09, 2024 at 10:06:47PM +0000, anlauf at gcc dot gnu.org wrote:
> 
> --- Comment #4 from anlauf at gcc dot gnu.org ---
> Created attachment 57374
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57374&action=edit
> Proof-of-concept patch
> 
> The attached - hackish - patch tries to avoid the infinite recursion by
> fixing up the character length especially for the intrinsics ADJUST[LR].
> 
> I'm not entirely happy with this, but could not yet find a better place.
> And in gfc_resolve_adjustl the backend_decl is not yet set.
> 

You're much quicker than I!  I only just identified the
infinite recursion and where it was occurring in the
scalarizer.  I got sidetrack on a whole different issue.

I'm wondering if we need to worry about other actual
arguments.  I note

subroutine test_adjustl(x)
  character(*) :: x(100)
   x = adjustl(x)
  call bar(x)
end subroutine

does not cause problems.

[Bug fortran/113845] ice in gfc_get_array_ss

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #5)
> I'm wondering if we need to worry about other actual
> arguments.  I note
> 
> subroutine test_adjustl(x)
>   character(*) :: x(100)
>    x = adjustl(x)
>   call bar(x)
> end subroutine
> 
> does not cause problems.

Playing around with variants, the common cause of the ICE seems:

1) assumed-length character dummy with rank > 0

e.g. these declarations fail too:

  character(*) :: x(*)
  character(*), allocatable :: x(:)

but not:

  character(:), allocatable :: x(:)

2) any reference that is not a substring

e.g.

  call bar(adjustl(x))
  call bar(adjustl(x(1:1)))
  call bar(adjustl(x(:)))
  call bar(adjustl(x(:)(:)))

but not

  call bar(adjustl(x(:)(1:len(x)))) ! <- this is OK

Quite obviously the attached patch is only a band-aid to prevent the
infinite recursion, not a real solution...