Hi Paul,
the patch fixes the ICE as advertised, so it is OK.
Thanks for the patch!
There is a small variation of the testcase where the assignment
leads to too many evaluations of the r.h.s., see attached testcase.
In this case 3 instead of one; other brands get this right.
Shall I open a separate PR for this problem?
Best,
Harald
On 3/26/26 15:16, Paul Richard Thomas wrote:
Hello All,
Thanks to Harald for pointing out this low hanging fruit to me.
The original ICE has changed to one that is easily identified and
fixed: dereferencing a NULL pointer in trans_allocate. This is fixed
in the third chunk. In this case, a symtree is now provided by a
modified version of gfc_get_unique symtree, which is the content of
the first chunk. Also, deallocation of non-variable, pointer source
allocatable components has been suppressed in the second chunk.
The resulting behaviour of the testcase has been tested against that
of other brands, since it wasn't evident to me from reading the F2018
standard that the deep copy of the allocatable component is correct.
Regtested on FC43/x86_64 - OK for mainline?
Paul
module m1
implicit none
type y
integer, allocatable :: x1(:)
end type y
type(y), target :: w
integer :: c = 0
contains
function f()
type(y), pointer :: f
f => w
c = c + 1
print *, "in f:"
end function
end
subroutine s2
use m1
implicit none
type(y), allocatable :: x
! type(y), pointer :: x
allocate (x)
print *, "before x = f()", c
x = f()
print *, "after x = f()", c
end
use m1
call s2
if (c > 1) print *, "Excessive number of evaluations of f!"
if (c /= 1) stop c+10
end
