| Issue |
135624
|
| Summary |
Use of Fortran TRANSFER intrinsic with argument of derived type containing allocatable causes double-free abort
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
krefson
|
Passing a derived type as the first argument to the TRANSFER intrinsic is arguably a bug in the Fortran standard, but flang's handling of it is sub-optimal. (Compiling without complaint, but causing run-rime memory issues).
````fortran
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 **input** argument, a, becomes deallocated, and valgrind shows that the memory has been freed.
A slightly more comprehensive test program is [struct_xfer.f90](https://github.com/user-attachments/files/19736198/struct_xfer.f90.txt)
See also my [posting to fortran-lang](https://fortran-lang.discourse.group/t/transfer-of-type-with-ultimate-allocatable-component/9570)
Other compilers also show a variety of undefined behaviour. gfortran for example manages to produce a shallow copy of `mytype`, but also generates a double-free error.
I suggest at least issuing a warning to expect undefined run-time behaviour!
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
