[Bug fortran/114470] New: [OOP] Defined, type-bound assignment(=) of component not called within class, allocatable parent

[Bug fortran/114470] New: [OOP] Defined, type-bound assignment(=) of component not called within class, allocatable parent

[Linxwiler_Benjamin at bah dot com]

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".