aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/StackProtector.cpp
diff options
context:
space:
mode:
authorSlava Zakharin <szakharin@nvidia.com>2025-07-16 12:11:15 -0700
committerGitHub <noreply@github.com>2025-07-16 12:11:15 -0700
commitbcee18a2e268dd106e4b3c2a1d083a4da21f4f23 (patch)
tree3accd12e5495f3b6b537207a9d9ff036c77d9edc /llvm/lib/CodeGen/StackProtector.cpp
parentc4d4e761ef27d6dd27323cf3efa506db5e9e3457 (diff)
downloadllvm-bcee18a2e268dd106e4b3c2a1d083a4da21f4f23.zip
llvm-bcee18a2e268dd106e4b3c2a1d083a4da21f4f23.tar.gz
llvm-bcee18a2e268dd106e4b3c2a1d083a4da21f4f23.tar.bz2
[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.
Diffstat (limited to 'llvm/lib/CodeGen/StackProtector.cpp')
0 files changed, 0 insertions, 0 deletions