[Bug fortran/109948] New: ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[Bug fortran/109948] New: ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[rimvydas.jas at gmail dot com]

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

            Bug ID: 109948
           Summary: ICE(segfault) in gfc_expression_rank() from
                    gfc_op_rank_conformable()
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

Bisected down to recent g:611be07e48956c8b7371eb580eef124990114fd3

$ cat test_associate.f90
subroutine foo(y, x)
implicit none
type tlap
  real,    allocatable :: z(:)
end type tlap
type(tlap) :: y
real :: x(:)
associate(z=>y%z)

if (getpid() == 1) then
  where ( z < 0.0 ) x(:) = z(:)
else
  where ( z < 0.0 ) x(:) = z(:)
endif

end associate
end subroutine foo

$ gfortran -O1 -c test_associate.f90
f951: internal compiler error: Segmentation fault
0xd362af crash_signal
        /data/g13/gcc/toplev.cc:314
0x2aaaaabfcecf ???
       
/tmp/glibc-2.37/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7ca895 gfc_expression_rank(gfc_expr*)
        /data/g13/gcc/fortran/resolve.cc:5643
0x7caa44 gfc_op_rank_conformable(gfc_expr*, gfc_expr*)
        /data/g13/gcc/fortran/resolve.cc:5676
0x71228c eval_intrinsic
        /data/g13/gcc/fortran/arith.cc:1669
0x789edc match_level_4
        /data/g13/gcc/fortran/matchexp.cc:646
0x789edc match_and_operand
        /data/g13/gcc/fortran/matchexp.cc:693
0x789f66 match_or_operand
        /data/g13/gcc/fortran/matchexp.cc:722
0x78a076 match_equiv_operand
        /data/g13/gcc/fortran/matchexp.cc:765
0x78a188 match_level_5gfc_op_rank_conformable(
        /data/g13/gcc/fortran/matchexp.cc:811
0x7892e4 gfc_match_expr(gfc_expr**)
        /data/g13/gcc/fortran/matchexp.cc:870
0x7bf2e0 match_actual_arg
        /data/g13/gcc/fortran/primary.cc:1688
0x7c0c88 gfc_match_actual_arglist(int, gfc_actual_arglist**, bool)
        /data/g13/gcc/fortran/primary.cc:1953
0x7c3455 gfc_match_rvalue(gfc_expr**)
        /data/g13/gcc/fortran/primary.cc:3695
0x7894fe match_primary
        /data/g13/gcc/fortran/matchexp.cc:157
0x7894fe match_level_1
        /data/g13/gcc/fortran/matchexp.cc:211
0x7894fe match_mult_operand
        /data/g13/gcc/fortran/matchexp.cc:267
0x7897c8 match_add_operand
        /data/g13/gcc/fortran/matchexp.cc:356
0x789a9c match_level_2
        /data/g13/gcc/fortran/matchexp.cc:480
0x789c56 match_level_3
        /data/g13/gcc/fortran/matchexp.cc:551
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug fortran/109948] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[rimvydas.jas at gmail dot com]

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

--- Comment #1 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
More trivial testcase resulting in similar ICE.

$ cat test_associate2.f90 
subroutine foo(grib)
implicit none
type b
  integer, allocatable :: k_2d(:)
end type
type(b) :: grib
integer :: i
associate(k=>grib%k_2d)
i = k(1)
if (any(k==1)) i = 1
end associate
end subroutine foo

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |anlauf at gcc dot gnu.org
            Summary|ICE(segfault) in            |[13/14 Regression]
                   |gfc_expression_rank() from  |ICE(segfault) in
                   |gfc_op_rank_conformable()   |gfc_expression_rank() from
                   |                            |gfc_op_rank_conformable()
   Last reconfirmed|                            |2023-05-24

--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.

Further reduced:

subroutine foo(y, x)
  implicit none
  real :: y(:)
  real :: x(:)

  associate(z=>y)
    where ( z < 0.0 ) x(:) = z(:)
    where ( z < 0.0 ) x(:) = z(:)
  end associate

end subroutine foo

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #1)
> More trivial testcase resulting in similar ICE.

Yep, even smaller:

subroutine foo(k_2d)
  implicit none
  integer :: k_2d(:)
  integer :: i
  associate(k=>k_2d)
    i = k(1)
    if (any(k==1)) i = 1
  end associate
end subroutine foo

The associate is apparently one of the common components that is needed.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
The following patch fixes NULL pointer dereference with the reduced
testcases:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 83e45f1b693..89c62b3eb1e 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5640,7 +5643,7 @@ gfc_expression_rank (gfc_expr *e)
       if (ref->type != REF_ARRAY)
        continue;

-      if (ref->u.ar.type == AR_FULL)
+      if (ref->u.ar.type == AR_FULL && ref->u.ar.as)
        {
          rank = ref->u.ar.as->rank;
          break;

Can you check if this works for you?

Still needs regtesting.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[rimvydas.jas at gmail dot com]

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

--- Comment #5 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
(In reply to anlauf from comment #4)
> Can you check if this works for you?

This patch allows to avoid issue on all other associate use cases (tried on
gcc-13 branch).

However it is a bit suspicious that using variable name abbreviations (to dig
out arrays from deeply nested types) is enough to change how the internal
gfc_array_ref is populated.  ICE was triggered only on patterns involving first
using abbreviated name indexed access (like k(1)) followed by any operation
involving whole array.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
   Target Milestone|---                         |13.2

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #5)
> (In reply to anlauf from comment #4)
> > Can you check if this works for you?
> 
> This patch allows to avoid issue on all other associate use cases (tried on
> gcc-13 branch).
> 
> However it is a bit suspicious that using variable name abbreviations (to
> dig out arrays from deeply nested types) is enough to change how the
> internal gfc_array_ref is populated.  ICE was triggered only on patterns
> involving first using abbreviated name indexed access (like k(1)) followed
> by any operation involving whole array.

I agree that this patch is a band-aid, possibly for some latent issue.
The suspect patch may have affected the order of resolution.

Note that replacing in the reduced testcase in comment#3:

  associate(k=>k_2d)

by

  associate(k=>k_2d(:))

avoids the ICE and gives identical code for gcc-12 .. gcc-14.  In fact,
the array-spec seems properly set.

I've added Paul in CC, who is more familiar with the associate construct.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Some more digging: in the case when ref->u.ar.as is NULL, it appears that

e->symtree->n.sym->assoc->target->ref->u.ar.as

is properly set.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[pault at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |87477

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> ---
I have flagged that this PR blocks PR87477.

Guarding ref->u.ar.as is good practice. However, it turns out that the
associate name symbol has a perfectly good array_spec. This version "double
fixes" the PR and is somewhat more satisfactory.

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 83e45f1b693..9863cdc1583 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5640,7 +5640,12 @@ gfc_expression_rank (gfc_expr *e)
       if (ref->type != REF_ARRAY)
        continue;

-      if (ref->u.ar.type == AR_FULL)
+      if (ref->u.ar.as == NULL
+         && e->expr_type == EXPR_VARIABLE
+         && e->symtree->n.sym->as)
+       ref->u.ar.as = e->symtree->n.sym->as;
+
+      if (ref->u.ar.type == AR_FULL && ref->u.ar.as)
        {
          rank = ref->u.ar.as->rank;
          break;

Gratifyingly, this does the right thing:

  implicit none
  type tlap
    real,    allocatable :: z(:)
  end type tlap
  type(tlap) :: y_in
  real :: x_out(3) =[0.0,0.0,0.0]
  integer :: pid = 1
  y_in%z = [1.0,-2.0,3.0]
  call foo(y_in, x_out)
  print *, x_out
  call foo(y_in, x_out)
  print *, x_out
contains
  subroutine foo(y, x)
    type(tlap) :: y
    real :: x(:)
    associate(z=>y%z)

    if (getpid() == 1) then
      where ( z < 0.0 ) x(:) = z(:)
    else
      where ( z > 0.0 ) x(:) = z(:)
    endif

    end associate
  end subroutine foo
  integer function getpid()
    getpid = pid
    pid = pid + 1
  end function getpid
end

Cheers

Paul


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
[Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas <pault at gcc dot gnu.org> ---
By the way, the patch regtests OK

Do you want to do the honours or shall I?

I think that this rates as an 'obvious' fix.

Paul

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

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

--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Paul Thomas from comment #8)
> I have flagged that this PR blocks PR87477.
> 
> Guarding ref->u.ar.as is good practice. However, it turns out that the
> associate name symbol has a perfectly good array_spec. This version "double
> fixes" the PR and is somewhat more satisfactory.
> 
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 83e45f1b693..9863cdc1583 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -5640,7 +5640,12 @@ gfc_expression_rank (gfc_expr *e)
>        if (ref->type != REF_ARRAY)
>         continue;
>  
> -      if (ref->u.ar.type == AR_FULL)
> +      if (ref->u.ar.as == NULL
> +         && e->expr_type == EXPR_VARIABLE
> +         && e->symtree->n.sym->as)
> +       ref->u.ar.as = e->symtree->n.sym->as;
> +
> +      if (ref->u.ar.type == AR_FULL && ref->u.ar.as)
>         {
>           rank = ref->u.ar.as->rank;
>           break;
> 

Mmh, in a sense it also "double breaks" it. For example, with
associate(z=>array(1)%ar(2,3)%array(:,:,:)), I expect to get the wrong as in
ref->u.ar.as for the last two array references.
You probably want to copy what's done in find_array_spec or directly call it?

My opinion remains that calling eval_intrinsic at parsing time (as it appears
we do from the stack trace) is fundamentally too early.  It doesn't make sure
that everything is properly set up, and that all the rules of the standard are
respected.  We wouldn't have this problem if the call to eval_intrinsic was
deferred to the resolution time.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #9)
> By the way, the patch regtests OK
> 
> Do you want to do the honours or shall I?
> 
> I think that this rates as an 'obvious' fix.

I think it does not handle the following variation of the testcase from
the blamed patch:


module mm
  implicit none
  interface operator(==)
     module procedure eq_1_2
  end interface operator(==)
  private :: eq_1_2
contains
  logical function eq_1_2 (x, y)
    integer, intent(in) :: x(:)
    real,    intent(in) :: y(:,:)
    eq_1_2 = .true.
  end function eq_1_2
end module mm

subroutine foo(k_2d)
  use mm
  implicit none
  integer :: k_2d(:)
  integer :: m(1) = 42
  real    :: r(1,1) = 3.0
  print *, (m == r)
  associate (k=>k_2d)
    print *, (k == r)   ! <-- fails
  end associate
  associate (k=>k_2d(:))
    print *, (k == r)
  end associate
end subroutine foo


For the marked line, I see in the debugger that e->ref == NULL.
I've played with some modification of the related code block, but that
regressed on two of the associate testcases.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #11)
> I think it does not handle the following variation of the testcase from
> the blamed patch:

This one seems to be handled by the clumsy attempt:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 75d61a18856..a5dcf07c1ee 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5622,6 +5625,21 @@ gfc_expression_rank (gfc_expr *e)
     {
       if (e->expr_type == EXPR_ARRAY)
        goto done;
+
+      /* Take rank from associate target.  */
+      if (e->symtree
+         && e->symtree->n.sym->as == NULL
+         && e->symtree->n.sym->assoc
+         && e->symtree->n.sym->assoc->target
+         && e->symtree->n.sym->assoc->rankguessed
+         && e->symtree->n.sym->assoc->target->ref
+         && e->symtree->n.sym->assoc->target->ref->u.ar.type == AR_FULL
+         && e->symtree->n.sym->assoc->target->ref->u.ar.as)
+       {
+         e->rank = e->symtree->n.sym->assoc->target->ref->u.ar.as->rank;
+         goto done;
+       }
+
       /* Constructors can have a rank different from one via RESHAPE().  */

       e->rank = ((e->symtree == NULL || e->symtree->n.sym->as == NULL)
@@ -5640,7 +5658,7 @@ gfc_expression_rank (gfc_expr *e)
       if (ref->type != REF_ARRAY)
        continue;

-      if (ref->u.ar.type == AR_FULL)
+      if (ref->u.ar.type == AR_FULL && ref->u.ar.as)
        {
          rank = ref->u.ar.as->rank;
          break;


Of course this does not address the point brought up by Mikael.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #12)
> +	  && e->symtree->n.sym->assoc->target->ref
> +	  && e->symtree->n.sym->assoc->target->ref->u.ar.type == AR_FULL
> +	  && e->symtree->n.sym->assoc->target->ref->u.ar.as)
> +	{
> +	  e->rank = e->symtree->n.sym->assoc->target->ref->u.ar.as->rank;
> +	  goto done;
> +	}
> +

Maybe be just need to follow the refs and join the code with the later part.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[pault at gcc dot gnu.org]

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

--- Comment #14 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi Mikael,


> Mmh, in a sense it also "double breaks" it. For example, with
> associate(z=>array(1)%ar(2,3)%array(:,:,:)), I expect to get the wrong as in
> ref->u.ar.as for the last two array references.
> You probably want to copy what's done in find_array_spec or directly call it?

Agreed - working both on parse_associate and gfc_expression_rank provides most
of the required repairs. However, the target expression is so incomplete during
parsing that this fails as before:

> 
> My opinion remains that calling eval_intrinsic at parsing time (as it
> appears we do from the stack trace) is fundamentally too early.  It doesn't
> make sure that everything is properly set up, and that all the rules of the
> standard are respected.  We wouldn't have this problem if the call to
> eval_intrinsic was deferred to the resolution time.


  subroutine comment10
    implicit none
    type(ulap) :: z(2)
    integer :: i
    real    :: r(1,1) = 3.0
    z(1)%u = [tlap([1,2,3]),tlap([4,5,6])]
    z(2)%u = [tlap([7,8,9]),tlap([10,11,12])]
    associate (k=>z(2)%u(1)%z)
      i = k(1)
      if (any(k==8)) i = 1                 ! This is OK
    end associate
    if (i .ne. 1) stop 8
    associate (k=>z(1)%u(2)%z)
      print *, k
      if ((k == r) .neqv. .true.) stop 9   ! Still broken
    end associate
  end subroutine comment10

Unfortunately, resolving the target expression in parse_associate causes a
large number of regressions (I stopped the regression test after the 'a's). So,
yes, you are quite right about the timing, especially in regard of operator
interfaces.

Andy Vaught's obsession with single pass parsing is biting us in the posterior.

I'll report back later on where I have got to with this PR.

Cheers

Paul

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[pault at gcc dot gnu.org]

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

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 #15 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 55225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55225&action=edit
Fix for this PR

The attached patch substantially tidies up parse_associate and fixes:

! { dg-do run }
!
! Tests the fix for PR109948
!
module mm
  implicit none
  interface operator(==)
    module procedure eq_1_2
  end interface operator(==)
  private :: eq_1_2
contains
  logical function eq_1_2 (x, y)
    integer, intent(in) :: x(:)
    real,    intent(in) :: y(:,:)
    eq_1_2 = .true.
  end function eq_1_2
end module mm

program pr109948
  use mm
  implicit none
  type tlap
    integer,    allocatable :: z(:)
  end type tlap
  type ulap
    type(tlap) :: u(2)
  end type ulap
  integer :: pid = 1
  call comment0         ! Original problem
  call comment1
  call comment3 ([5,4,3,2,1])
  call comment10
  call comment11 ([5,4,3,2,1])
contains
  subroutine comment0
    type(tlap) :: y_in
    integer :: x_out(3) =[0.0,0.0,0.0]
    y_in%z = [1,-2,3]
    call foo(y_in, x_out)
    if (any (x_out .ne. [0, -2, 0])) stop 1
    call foo(y_in, x_out)
    if (any (x_out .ne. [1, -2, 3])) stop 2
  end subroutine comment0

  subroutine foo(y, x)
    type(tlap) :: y
    integer :: x(:)
    associate(z=>y%z)
      if (pid == 1) then
        where ( z < 0 ) x(:) = z(:)
      else
        where ( z > 0 ) x(:) = z(:)
    endif
    pid = pid + 1
    end associate
  end subroutine foo

  subroutine comment1
    type(tlap) :: grib
    integer :: i
    grib%z = [3,2,1]
    associate(k=>grib%z)
      i = k(1)
      if (any(k==1)) i = 1
    end associate
    if (i .eq. 3) stop 3
  end subroutine comment1

  subroutine comment3(k_2d)
    implicit none
    integer :: k_2d(:)
    integer :: i
    associate(k=>k_2d)
      i = k(1)
      if (any(k==1)) i = 1
    end associate
    if (i .eq. 3) stop 4
  end subroutine comment3

  subroutine comment11(k_2d)
    implicit none
    integer :: k_2d(:)
    integer :: m(1) = 42
    real    :: r(1,1) = 3.0
    if ((m == r) .neqv. .true.) stop 5
    associate (k=>k_2d)
      if ((k == r) .neqv. .true.) stop 6  ! failed to find user defined
operator
    end associate
    associate (k=>k_2d(:))
      if ((k == r) .neqv. .true.) stop 7
    end associate
  end subroutine comment11

  subroutine comment10
    implicit none
    type(ulap) :: z(2)
    integer :: i
    real    :: r(1,1) = 3.0
    z(1)%u = [tlap([1,2,3]),tlap([4,5,6])]
    z(2)%u = [tlap([7,8,9]),tlap([10,11,12])]
    associate (k=>z(2)%u(1)%z)
      i = k(1)
      if (any(k==8)) i = 1
    end associate
    if (i .ne. 1) stop 8
    associate (k=>z(1)%u(2)%z)
      if ((k == r) .neqv. .true.) stop 9
      if (any (k .ne. [4,5,6])) stop 10
    end associate
  end subroutine comment10
end program pr109948

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #15)
> Created attachment 55225 [details]
> Fix for this PR
> 
> The attached patch substantially tidies up parse_associate and fixes:

LGTM!

I was close to proposing a hack for gfc_expression_rank that checks
whether the variable's select_type_temporary, select_rank_temporary and
associate_var attributes to decide which ref to evaluate.  But your
patch seems to be a much better approach.

BTW: after your patch, the attribute assoc->rankguessed is no longer set.
It is tested in two locations in resolve_assoc_var(resolve.cc), where
it might be removed after your fix.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[mikael at gcc dot gnu.org]

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

--- Comment #17 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #16)
> (In reply to Paul Thomas from comment #15)
> > Created attachment 55225 [details]
> > Fix for this PR
> > 
> > The attached patch substantially tidies up parse_associate and fixes:
> 
> LGTM!
> 
Yes, nice work.  I didn't expect such a simple fix.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 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:3c2eba4b7a2355ed5099e35332388206c484744d

commit r14-1487-g3c2eba4b7a2355ed5099e35332388206c484744d
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Fri Jun 2 08:41:45 2023 +0100

    Fortran: Fix some problems blocking associate meta-bug [PR87477]

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

    gcc/fortran
            PR fortran/87477
            * parse.cc (parse_associate): Replace the existing evaluation
            of the target rank with calls to gfc_resolve_ref and
            gfc_expression_rank. Identify untyped target function results
            with structure constructors by finding the appropriate derived
            type.
            * resolve.cc (resolve_symbol): Allow associate variables to be
            assumed shape.

    gcc/testsuite/
            PR fortran/87477
            * gfortran.dg/associate_54.f90 : Cope with extra error.

            PR fortran/102109
            * gfortran.dg/pr102109.f90 : New test.

            PR fortran/102112
            * gfortran.dg/pr102112.f90 : New test.

            PR fortran/102190
            * gfortran.dg/pr102190.f90 : New test.

            PR fortran/102532
            * gfortran.dg/pr102532.f90 : New test.

            PR fortran/109948
            * gfortran.dg/pr109948.f90 : New test.

            PR fortran/99326
            * gfortran.dg/pr99326.f90 : New test.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[pault at gcc dot gnu.org]

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

--- Comment #19 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to anlauf from comment #16)
> (In reply to Paul Thomas from comment #15)
> > Created attachment 55225 [details]
> > Fix for this PR
> > 
> > The attached patch substantially tidies up parse_associate and fixes:
> 
> LGTM!
> 
> I was close to proposing a hack for gfc_expression_rank that checks
> whether the variable's select_type_temporary, select_rank_temporary and
> associate_var attributes to decide which ref to evaluate.  But your
> patch seems to be a much better approach.
> 
> BTW: after your patch, the attribute assoc->rankguessed is no longer set.
> It is tested in two locations in resolve_assoc_var(resolve.cc), where
> it might be removed after your fix.

On the latter => yes indeed!

I see that I had a fix for pr109451, which was never submitted. I am going to
shake the dust off the patch and will set about removing rankguessed.

Thanks

Paul

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[pault at gcc dot gnu.org]

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

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

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

--- Comment #20 from Paul Thomas <pault at gcc dot gnu.org> ---
Fixed on trunk. I am closing the PR for housekeeping purposes but will include
the patch in future backports.

Thanks for the report.

Paul

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:d6997a5aab7aaa325946a6283bfee8ac2bd9f540

commit r13-7761-gd6997a5aab7aaa325946a6283bfee8ac2bd9f540
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sun Aug 27 09:51:32 2023 +0100

    Fortran: Fix some problems blocking associate meta-bug [PR87477]

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

    gcc/fortran
            PR fortran/87477
            * parse.cc (parse_associate): Replace the existing evaluation
            of the target rank with calls to gfc_resolve_ref and
            gfc_expression_rank. Identify untyped target function results
            with structure constructors by finding the appropriate derived
            type.
            * resolve.cc (resolve_symbol): Allow associate variables to be
            assumed shape.

    gcc/testsuite/
            PR fortran/87477
            * gfortran.dg/associate_54.f90 : Cope with extra error.

            PR fortran/102109
            * gfortran.dg/pr102109.f90 : New test.

            PR fortran/102112
            * gfortran.dg/pr102112.f90 : New test.

            PR fortran/102190
            * gfortran.dg/pr102190.f90 : New test.

            PR fortran/102532
            * gfortran.dg/pr102532.f90 : New test.

            PR fortran/109948
            * gfortran.dg/pr109948.f90 : New test.

            PR fortran/99326
            * gfortran.dg/pr99326.f90 : New test.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexandre.poux at coria dot fr

--- Comment #22 from anlauf at gcc dot gnu.org ---
*** Bug 111321 has been marked as a duplicate of this bug. ***

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #23 from anlauf at gcc dot gnu.org ---
The fix was applied to 13-branch after the 13.2 release.
Updating target milestone appropriately.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |antoine.lemoine@bordeaux-in
                   |                            |p.fr

--- Comment #24 from anlauf at gcc dot gnu.org ---
*** Bug 111618 has been marked as a duplicate of this bug. ***