https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114470
Bug ID: 114470
Summary: [OOP] Defined, type-bound assignment(=) of component
not called within class, allocatable parent
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Linxwiler_Benjamin at bah dot com
Target Milestone: ---
The following code prints
42
42
with gfortran and
42
7
with ifort (2021.11.1 20231117) and ifx (2024.0.2 20231213).
Per my reading of the relevant portions of the standard (given below), the
latter is the correct behavior.
module myMod
implicit none
type component
integer :: i = 42
contains
generic :: assignment(=) => copy
procedure :: copy
end type
type container
type(component) :: foo
end type
contains
subroutine copy(lhs,rhs)
class(component), intent(out) :: lhs
class(component), intent(in) :: rhs
lhs%i = 7
end subroutine
end module
program main
use myMod
implicit none
type(container) :: right
! type(container), allocatable :: left
class(container), allocatable :: left
print *, right%foo%i
left = right
print *, left%foo%i
end program
If "left" in the program is made "type, allocatable" instead of "class,
allocatable", then the program prints
42
7
as expected.
The relevant portions of the Fortran 2008 standard are found in "7.2.1.3
Interpretation of intrinsic assignments" and are as follows:
- Per paragraph 3 (excerpt):
"If the variable is or becomes an unallocated allocatable variable, it is
then allocated with
- if the variable is polymorphic, the same dynamic type as expr..."
- Per paragraph 13 (excerpt):
"An intrinsic assignment where the variable is of derived type is performed
as if each component of the variable were assigned from the corresponding
component of expr using... defined assignment for each nonpointer
nonallocatable conponent of a type that has a type-bound defined assignment
consistent with the component..."
Paragraph 3 pertains to assignment of "left" while paragraph 13 explains the
assignment of component "foo".
This issue is related to the following bugs, with the following similarities
and differences:
- For PR46897 [solved], both issues involve a defined, type-bound assignment
on
a component that is not being called. The difference is with the container
holding the object; it is "class, allocatable" in this new issue.
- For PR57696 [unsolved], both issues involved a defined, type-bound
assignment
on a component that is not being called. The difference is that the
component
is "type, allocatable" while the container holding it is "type" in the
previous issue, and in the new issue, the component is "type" while the
container holding it is "class, allocatable".
- For PR57697 [solved], both issues are the same except that in the former the
container holding the component is "type, allocatable" while in the latter
it
is "class, allocatable".
