https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128478
Bug ID: 128478
Summary: Parenthesized scalar CLASS actual argument is not a
copy of the variable
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Target Milestone: ---
A parenthesized variable is an expression, so the dummy argument
associated with "(q)" must not alias q. When q is a scalar CLASS
variable, gfortran passes q itself, and a change to the variable
through another argument shows up in the dummy:
program p
implicit none
complex, target :: zs = (5., 6.)
class(*), pointer :: q
q => zs
call sq ((q), zs)
contains
subroutine sq (x, z)
class(*), intent(in) :: x
complex, intent(inout) :: z
z = (0., 0.)
select type (x)
type is (complex)
if (x /= (5., 6.)) stop 1
end select
end subroutine
end program
% gfortran pr.f90 && ./a.out
STOP 1
Expected: no output; x keeps the value (5.,6.) that q had at the call.
CLASS(t) with an allocatable component behaves the same way.
Passing a parenthesized CLASS variable to a TYPE dummy segfaults
instead, because the code that runs after the call treats the CLASS
container as the derived type:
module m
implicit none
type :: t
integer, allocatable :: v(:)
end type
contains
subroutine s1 (x)
type(t), intent(in) :: x
if (x%v(2) /= 2) stop 1
end subroutine
end module
program p
use m
implicit none
class(t), allocatable :: cs
allocate (cs, source = t ([2, 2]))
call s1 ((cs))
end program
% gfortran pr2.f90 && ./a.out
Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.
This came out of PR128357, where it was mixed in with memory leaks
from parenthesized variables of types with allocatable components.
A fix for the CLASS-dummy case is in progress; the TYPE-dummy case
is not yet fixed.
