diff options
author | Peter Klausler <pklausler@nvidia.com> | 2023-03-17 14:13:39 -0700 |
---|---|---|
committer | Peter Klausler <pklausler@nvidia.com> | 2023-03-27 17:01:41 -0700 |
commit | bb6faec1818026a5b7ead29ff98511784ce2cfdd (patch) | |
tree | 3e4258da295fa2f17fe19478d384b887709c036c /llvm/unittests/ExecutionEngine/Orc/ExecutionSessionWrapperFunctionCallsTest.cpp | |
parent | 36c8a9a9830a321d2b5e3d9dd5b2e7c7da5c56ac (diff) | |
download | llvm-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