https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800
Bug ID: 119800
Summary: Use of Fortran TRANSFER intrinsic with argument of
derived type containing allocatable causes double-free
abort
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: krefson at gmail dot com
Target Milestone: ---
Created attachment 61111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61111&action=edit
Fortran program source code demonstrating behaviour with TRANSFER intrinsic
Passing a derived type as the first argument to the TRANSFER intrinsic is
arguably a bug in the Fortran standard, but gfortran's handling of it is
sub-optimal. (Compiling without complaint, but causing run-time memory issues).
program transfer_test
type mytype
real, allocatable, dimension(:) :: c
end type mytype
type(mytype) :: a, b
allocate(a%c(8))
b = transfer(a, b)
write(*,*) 'Storage (as integer) of a = ',
storage_size(a)/storage_size('a')
write(*,*) 'Storage (as integer) of b = ',
storage_size(b)/storage_size('a')
print *, 'Allocation status(a,b)=', allocated(a%c),allocated(b%c)
if( allocated(b%c)) deallocate(b%c)
print *, 'Allocation status(a,b)=', allocated(a%c),allocated(b%c)
if( allocated(a%c)) deallocate(a%c)
end program transfer_test
Following the TRANSFER statement the allocatable in the output argument, a,
becomes associated with the same storage as the input argument. A subsequent
DEALLOCATE of both causes a double-free error.
A slightly more comprehensive test program is attached
See also my posting to fortran-lang
Other compilers also show a variety of undefined behaviour. flang for example
manages to deallocate the input variable, but also generates a double-free
error.
I suggest at least issuing a warning to expect undefined run-time behaviour!
