aboutsummaryrefslogtreecommitdiff
path: root/lldb/packages/Python/lldbsuite/test/configuration.py
diff options
context:
space:
mode:
authorJean Perier <jperier@nvidia.com>2023-05-25 17:42:04 +0200
committerJean Perier <jperier@nvidia.com>2023-05-25 17:43:44 +0200
commitd07f23e033220b7fbc47b40172de647c09364c62 (patch)
treeee75752de01f3474c0cc9f10950bc375dcda0fc1 /lldb/packages/Python/lldbsuite/test/configuration.py
parent291223409c6139b5d56efc769088e23ecee44faf (diff)
downloadllvm-d07f23e033220b7fbc47b40172de647c09364c62.zip
llvm-d07f23e033220b7fbc47b40172de647c09364c62.tar.gz
llvm-d07f23e033220b7fbc47b40172de647c09364c62.tar.bz2
[flang][hlfir] Use actual type when copying an actual argument variable
The copy must made according to the actual type, not the dummy type. In case the dummy is polymorphic, these types will be different and the dynamic type of the copy passed in the call should be the one of the actual. There is no support for "class(t), value" yet (it is hitting a TODO in CallInterface that is moot for HLFIR but has not been lifted for lack of proper testing) so the bug was dormant, but D151271 created a situation where a copy is needed with polymorphic dummies and exposed the bug. This led to a compile time assert "value.isScalar() && fir::isa_trivial(value.getType())" in "hlfir::genAssociateExpr". Differential Revision: https://reviews.llvm.org/D151413
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/configuration.py')
0 files changed, 0 insertions, 0 deletions