An INTENT(IN) attribute on a pointer dummy argument prevents
modification of the pointer itself only, not modification of any
component of its target. Fix this case without breaking definability
checking for pointer components of non-pointer INTENT(IN) dummy
arguments.
Changed semantic check from giving error to giving a warning about
deprecation from OpenMP 5.2 and later about checks for dummy argument
list-items present on IS_DEVICE_PTR clause.
This P is blocker for
https://github.com/llvm/llvm-project/pull/71255
Preliminary patch to change lowering/code generation to use
llvm::DataLayout information instead of generating "sizeof" GEP (see
https://github.com/llvm/llvm-project/issues/71507).
Fortran Semantic analysis needs to know about the target type size and
alignment to deal with common blocks, and intrinsics like
C_SIZEOF/TRANSFER. This information should be obtained from the
llvm::DataLayout so that it is consistent during the whole compilation
flow.
This change is changing flang-new and bbc drivers to:
1. Create the llvm::TargetMachine so that the data layout of the target
can be obtained before semantics.
2. Sharing bbc/flang-new set-up of the
SemanticConstext.targetCharateristics from the llvm::TargetMachine. For
now, the actual part that set-up the Fortran type size and alignment
from the llvm::DataLayout is left TODO so that this change is mostly an
NFC impacting the drivers.
3. Let the lowering bridge set-up the mlir::Module datalayout attributes
since it is doing it for the target attribute, and that allows the llvm
data layout information to be available during lowering.
For flang-new, the changes are code shuffling: the `llvm::TargetMachine`
instance is moved to `CompilerInvocation` class so that it can be used
to set-up the semantic contexts. `setMLIRDataLayout` is moved to
`flang/Optimizer/Support/DataLayout.h` (it will need to be used from
codegen pass for fir-opt target independent testing.)), and the code
setting-up semantics targetCharacteristics is moved to
`Tools/TargetSetup.h` so that it can be shared with bbc.
As a consequence, LLVM targets must be registered when running
semantics, and it is not possible to run semantics for a target that is
not registered with the -triple option (hence the power pc specific
modules can only be built if the PowerPC target is available.
1. COPYPRIVATE clause should be specified on END SINGLE construct.
2. NOWAIT clause should be specified on END DO/DO SIMD/SINGLE/SECTIONS
construct.
Special handling for semantic checks for nowait/copyprivate clause is
needed in Fortran due to the fact that Openmp pragmas for C/C++ doesn't
have end directive (clause). nowait/copyprivate clauses are allowed in
begin directive clause lists for C/C++ and it is not allowed for
Fortran.
…ion result)
A function can't return a statement function, so an apparent attempt to
define a statement function with the same name as the function's result
must be a misparsed assignment statement.
Some clauses can be repeated on the compute construct when they are
placed after `device_type`. The semantic check was reporting an error
for these cases. This patch fixes this.
Array element references are frequently parsed as function references
due to the ambiguous syntax of Fortran, and the parse tree is repaired
by semantics once the relevant symbol table entries are in hand. This
patch fixes a case in which the correction takes a path that leaves the
type of a symbol undetermined, leading to later spurious errors in
expression analysis.
Fixes https://github.com/llvm/llvm-project/issues/68652.
…arrays
When comparing dummy array extents, cope with references to symbols
better (including references to other dummy arguments), and emit
warnings in dubious cases that are not equivalent but not provably
incompatible.
Move the code to check the arguments of references to the intrinsic
function REDUCE() into Semantics/check-calls.cpp, and add checks for
several requirements from the standard that weren't yet caught.
The compiler will now emit an error for length == 0 and an
off-by-default portability warning for length > 1. Previously, the
message was an unconditional warning for length /= 1.
Unlike mentioned in #73839, some OpenACC construct still need the cycle
branching check to be performed. This patch adds a list of construct
where the check is not needed (loop and combined construct) and add
tests to check where it is still needed.
This patch adds the following semantic check:
```
The ancestor device-modifier must not appear on the device clause on any
directive other than the target construct.
```
This patch adds the following check from OpenMP 5.2.
```
If the directive has a clause, it must contain at least one enter clause
or at least one link clause.
```
Also added a warning for the deprication of `TO` clause on `DECLARE
TARGET` construct.
```
The clause-name to may be used as a synonym for the clause-name enter.
This use has been deprecated.
```
Based on the tests for to clause, the tests for enter clause are added.
This patch does not add tests where both to and enter clause are used together.
When a BLOCK construct is within an ASSOCIATE or related construct,
don't misinterpret an assignment to an array element of a construct
entity as being an impermissible definition of a local statement
function.
It is possible to declare the rank of an object after that object has
been used in the same specification part in a specification function
reference whose result or generic resolution may well have depended on
the object being apparently a scalar.
Catch this case, and emit a warning -- not an error, yet, due to fear of
false positives.
See the new test for examples.
Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair number of
sites in the code do not, and can emit portability warnings
unconditionally, which can confuse a user that hasn't asked for them
(-pedantic) and isn't terribly concerned about portability *to* other
compilers.
Add calls to ShouldWarn() or IsEnabled() around messages that need them,
and add -pedantic to tests that now require it to test their portability
messages, and add more expected message lines to those tests when
-pedantic causes other diagnostics to fire.
Compilation-time subscript value range checking should emit a warning,
not an error, when the indexed array is a dummy argument; there's
old-school codes out there that should have used assumed-size dummy
arguments but didn't.
I explicitly skipped definability checking for construct entities under
a RANK() clause. I don't know what I was thinking at the time; it's
obviously incorrect! Fix, and add tests.
A NULL() pointer without MOLD= cannot be allowed to be associated with
an assumed-rank dummy argument, as its rank is not well-defined and
neither the RANK() intrinsic function or the SELECT RANK construct will
work in the callee.
When the bounds of a substring reference are known during compilation,
and are outside the valid range for the character base object, issue an
error message.
…forwarded to CONTIGUOUS dummy
No object with the ASYNCHRONOUS or VOLATILE attribute can go through the
copy-in/copy-out protocol necessary for argument association with a
contiguous dummy array argument. The check for this constraint missed
the case of an assumed-rank array without an explicit CONTIGUOUS
attribute being forwarded on to a CONTIGUOUS dummy argument.
Semantics is emitting an error when an actual argument to a procedure
that has an implicit interface has a polymorphic type. This is too
general; while TYPE(*) and CLASS(*) unlimited polymorphic items require
the presence of an explicit procedure interface, CLASS(T) data can be
passed over an implicit interface to a procedure expecting a
corresponding dummy argument with TYPE(T), so long as T is not
parameterized.
(Only XLF handles this usage correctly among other Fortran compilers.)
(Making this work in the case of an actual CLASS(T) array may well
require additional changes in lowering to copy data to/from a temporary
buffer to ensure contiguity when the actual type of the array is an
extension of T.)
This patch adds a semantic check for the following:
```
If a list item is a procedure name, it must not be a generic name,
procedure pointer, entry name, or statement function name.
```
This patch adds the following semantic check for is_device_ptr
```
A list item that appears in an is_device_ptr clause must be a
dummy argument that does not have the ALLOCATABLE, POINTER or
VALUE attribute.
```
If the symbol is already privatized due to a user specification then it
is not required to mark it as PreDetermined. This happens if there is a
sequential loop in a parallel region that has the private specification
for the index of the sequential loop.
Fixes#63143
This patch adds the following semantic check for target update
```
At least one motion-clause must be specified.
```
A motion clause is either a `to` or a `from` clause.
This patch also adds a test for the following semantic check which was
already supported.
```
At most one nowait clause can appear on the directive.
```
As an extension, accept the redundant use of the CONTIGUOUS attribute
when applied to scalars and to simply contiguous objects, with a
portability warning.
The online CUDA Fortran documentation states that a device subprogram
must be a top-level module subprogram, but this has turned out to be an
obsolete constraint. Stop enforcing it.
Fix IsDescriptor() so that it doesn't return a false negative result
that messes up compatibility checking between a separate module
procedure's interface and its redundant definition (without MODULE
PROCEDURE). Specifically, lower bounds just don't matter, and any upper
bound that's not explicit is dispositive.
... when the derived type used in the structure constructor(s) is from
another module and not use-associated into the current module.
This came up in a test with a derived type component default initializer
of "c_null_ptr", which is replaced with the expression
"__builtin_c_ptr(address=0_8)"; the derived type name "__builtin_c_ptr"
is not available in the current scope, and the module file would fail
semantic analysis when USE'd.
The best solution that I found was to extend module file generation to
detect this case and handle it by inserting the right USE association to
the ultimate derived type symbol, possibly with renaming to a
compiler-created name in the case of a conflict.
To implement this transformation, it was necessary to fix the utility
evaluate::CollectSymbols() to include the derived type symbol from a
structure constructor. This involved extending the expression traversal
framework to visit the derived type spec of a structure constructor.
Extending CollectSymbols() caused a lowering test to fail mysteriously,
so I tracked down the code in PFTBuilder that didn't expect to see a
DerivedTypeDetails symbol and dealt with it there.
When a separate module function's definition has a redundant interface
-- it's defined with MODULE FUNCTION, not MODULE PROCEDURE -- the check
for result type equivalence needs to allow for character lengths that
are the results of specification expressions. At present,
identical-looking length specification expression don't compare equal,
since they can refer to distinct dummy argument symbols. Ensure just
that they are both constant or not, and if constant, that the lengths
have the same value.
Name resolution takes a quick pass over the executable part of a
(sub)program in search of symbols that appear to be called as
procedures, so that those names don't get mistakenly converted into
objects when finishing up specification part processing. This pass
doesn't currently cope with symbol shadowing by nested declarations in
executable constructs. This patch ensures that nested declarations for
symbols that could be used in contexts that might have been parsed as
function references properly shadow symbols of the same name in outer
scopes.
When a derived type definition is visible by two or more names in the
same scope due to USE renaming, any generic ASSIGNMENT(=) or OPERATOR()
bindings in the type will produce incorrect error messages about
indistinguishable specific procedures. This is due to the use of a
std::vector<> to hold a sequence of symbols and some derived information
for the specific procedures of the generic name. Change to a std::map<>
indexed by the ultimate symbol of each specific so that duplicates
cannot arise.
…nversion
As requested by people working on lowering: when semantics converts the
contents of DATA statements into explicit object initializers, ensure
that structure constructors for derived types contain explicit NULL()
values for their allocatable components.
When a procedure with an implicit interface is called from two call
sites with distinct argument types, we emit a warning. This can lead to
a lot of output when the actual argument types are differing-length
character, and the warnings are less important since the procedure may
well have been defined with assumed-length character dummy arguments. So
let cases like CALL MYERROR('ab'); CALL MYERROR('abc') slide by without
a warning.
