aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/ExecutionEngine/Orc/ExecutionSessionWrapperFunctionCallsTest.cpp
diff options
context:
space:
mode:
authorPeter Klausler <pklausler@nvidia.com>2023-03-17 14:13:39 -0700
committerPeter Klausler <pklausler@nvidia.com>2023-03-27 17:01:41 -0700
commitbb6faec1818026a5b7ead29ff98511784ce2cfdd (patch)
tree3e4258da295fa2f17fe19478d384b887709c036c /llvm/unittests/ExecutionEngine/Orc/ExecutionSessionWrapperFunctionCallsTest.cpp
parent36c8a9a9830a321d2b5e3d9dd5b2e7c7da5c56ac (diff)
downloadllvm-bb6faec1818026a5b7ead29ff98511784ce2cfdd.zip
llvm-bb6faec1818026a5b7ead29ff98511784ce2cfdd.tar.gz
llvm-bb6faec1818026a5b7ead29ff98511784ce2cfdd.tar.bz2
[flang] Tune handling of LEN type parameter discrepancies on ALLOCATE
Presently, semantics doesn't check for discrepancies between known constant corresponding LEN type parameters between the declared type of an allocatable/pointer and either the type-spec or the SOURCE=/MOLD= on an ALLOCATE statement. This allows discrepancies between character lengths to go unchecked. Some compilers accept mismatched character lengths on SOURCE=/MOLD= and the allocate object, and that's useful and unambiguous feature that already works in f18 via truncation or padding. A portability warning should issue, however. But for mismatched character lengths between an allocate object and an explicit type-spec, and for any mismatch between derived type LEN type parameters, an error is appropriate. Differential Revision: https://reviews.llvm.org/D146583
Diffstat (limited to 'llvm/unittests/ExecutionEngine/Orc/ExecutionSessionWrapperFunctionCallsTest.cpp')
0 files changed, 0 insertions, 0 deletions