[all-commits] [llvm/llvm-project] bcee18: [flang] Handle SEQUENCE derived types for array re...

[Slava Zakharin via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bcee18a2e268dd106e4b3c2a1d083a4da21f4f23
      https://github.com/llvm/llvm-project/commit/bcee18a2e268dd106e4b3c2a1d083a4da21f4f23
  Author: Slava Zakharin <szakharin at nvidia.com>
  Date:   2025-07-16 (Wed, 16 Jul 2025)

  Changed paths:
    M flang/lib/Optimizer/CodeGen/LowerRepackArrays.cpp
    M flang/test/Transforms/lower-repack-arrays.fir

  Log Message:
  -----------
  [flang] Handle SEQUENCE derived types for array repacking. (#148777)

It is possible that a non-polymorphic dummy argument
has a dynamic type that does not match its static type
in a valid Fortran program, e.g. when the actual and
the dummy arguments have different compatible derived
SEQUENCE types:
module mod
  type t
    sequence
    integer x
  end type
contains
  subroutine test(x)
    type t
      sequence
      integer x
    end type
    type(t) :: x(:)
  end subroutine
end module

'test' may be called with an actual argument of type 'mod::t',
which is the dynamic type of 'x' on entry to 'test'.
If we create the repacking temporary based on the static type of 'x'
('test::t'), then the runtime will report the types mismatch
as an error. Thus, we have to create the temporary using
the dynamic type of 'x'. The fact that the dummy's type
has SEQUENCE or BIND attribute is not easily computable
at this stage, so we use the dynamic type for all derived
type cases. As long as this is done only when the repacking
actually happens, the overhead should not be noticeable.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications