Whilst a little contrived, OpenMP allows you to utilise declare target
in the scope of one function to mark another function declare target,
currently this leads to a semantic error.
This appears to be because when we process the declare target directive
in the scope of another function (referring to another function), we do
not search externally from that functions scope to find possible prior
definitions, we only search in the current scope, this leads to us
implicitly defining a new variable and using that when implicit none is
not specified and then error'ng out or error'ng out earlier when implict
none is defined. This patch tries to address this behaviour by looking
externally for a function first and using that, before defaulting back
to the prior behaviour.
A module can't USE itself, either directly within the top-level module
or from one of its submodules. Add a test for this case (which we
already caught), and improve the diagnostic for the more confusing case
involving a submodule.
When the same name is used for distinct derived types in two modules,
and at least one of those modules also defines a generic interface of
the same name, name resolution crashes when both modules are USE'd into
the same scope. The crash is due to some pointers into the symbol table
becoming invalid when a symbol is replaced with a UseErrorDetails; set
them to null. Also allow for extending a UseErrorDetails in place rather
than emitting a spurious error message.
Fixes https://github.com/llvm/llvm-project/issues/121718.
Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).
This is nearly identical to the UNSIGNED feature that has been available
in Sun Fortran for years, and now implemented in GNU Fortran for
gfortran 15, and proposed for ISO standardization in J3/24-116.txt.
See the new documentation for details; but in short, this is C's
unsigned type, with guaranteed modular arithmetic for +, -, and *, and
the related transformational intrinsic functions SUM & al.
This removes the specialized parsers and helper classes for these
clauses, namely ConcatSeparated, MapModifiers, and MotionModifiers. Map
and the motion clauses are now handled in the same way as all other
clauses with modifiers, with one exception: the commas separating their
modifiers are optional. This syntax is deprecated in OpenMP 5.2.
Implement version checks for modifiers: for a given modifier on a given
clause, check if that modifier is allowed on this clause in the
specified OpenMP version. This replaced several individual checks.
Add a testcase for handling map modifiers in a different order, and for
diagnosing an ultimate modifier out of position.
This prepares for using the DECLARE MAPPER construct.
A check in lowering will say "Not implemented" when trying to use a
mapper as some code is required to tie the mapper to the declared one.
Senantics check for the symbol generated.
When skimmming executable parts to collect names used in procedure
calls, it is important to exclude names that have local declarations in
nested BLOCK constructs. The mechanism for handling these nested
declarations was catching only names whose declarations include an
"entity-decl", and so names appearing in other declaration statements
(like INTRINSIC and EXTERNAL statements) were not hidden from the scan,
leading to absurd error messages when such names turn out to be
procedures in the nested BLOCK construct but to not be procedures
outside it.
This patch fixes the code that detects local declarations in BLOCK for
all of the missed cases that don't use entity-decls; only INTRINSIC and
EXTERNAL could affect the procedures whose names are of interest to the
executable part skimmer, but perhaps future work will want to collect
non-procedures as well, so I plugged all of the holes that I could find.
Fixes https://github.com/llvm/llvm-project/issues/115674.
Define `OmpIteratorSpecifier` and `OmpIteratorModifier` parser classes,
and add parsing for them. Those are reusable between any clauses that
use iterator modifiers.
Add support for iterator modifiers to the MAP clause up to lowering,
where a TODO message is emitted.
ProgramTree instances are created as the value of a local variable in
the Pre(const parser::ProgramUnit &) member function in name resolution.
But references to these ProgramTree instances can persist in
SubprogramNameDetails symbol table entries that might survive that
function call's lifetime, and lead to trouble later when (e.g.)
expression semantics needs to deal with a possible forward reference in
a function reference in an expression being processed later in
expression checking.
So put those ProgramTree instances into a longer-lived linked list
within the SemanticsContext.
Might fix some weird crashes reported on big-endian targets (AIX &
Solaris).
(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as expected.)
Allow a parser::Message for a warning to be marked with the
common::LanguageFeature or common::UsageWarning that controls it. This
will allow a later patch to add hooks whereby a driver will be able to
decorate warning messages with the names of its options that enable each
particular warning, and to add hooks whereby a driver can map those
enumerators by name to command-line options that enable/disable the
language feature and enable/disable the messages.
The default settings in the constructor for LanguageFeatureControl were
moved from its header file into its C++ source file.
Hooks for a driver to use to map the name of a feature or warning to its
enumerator were also added.
To simplify the tagging of warnings with their corresponding language
feature or usage warning, to ensure that they are properly controlled by
ShouldWarn(), and to ensure that warnings never issue at code sites in
module files, two new Warn() member function templates were added to
SemanticsContext and other contextual frameworks. Warn() can't be used
before source locations can be mapped to scopes, but the bulk of
existing code blocks testing ShouldWarn() and FindModuleFile() before
calling Say() were convertible into calls to Warn(). The ones that were
not convertible were extended with explicit calls to
Message::set_languageFeature() and set_usageWarning().
A recent fix to the emission of derived type names to module files
exposed a regression in the case of a derived type that (1) has the same
name as a generic procedure interface and (2) has undergone renaming
through USE association before (3) being used in a declaration
significant to a module procedure interface. Fix.
The order of operations in name resolution wasn't converting named
entities to objects by the time that they were subjected to the implicit
typing rules in the case of interface blocks. This led to entities
remaining untyped without error, leading to a crash in module file
generation.
Fixes https://github.com/llvm/llvm-project/issues/108975.
A derived type specification in semantics holds both its source name
(for location purposes) and its ultimate derived type symbol. But for
correct module file generation of a structure constructor using that
derived type spec, the original symbol may be needed so that USE
association can be exposed.
Save both the original symbol and its ultimate symbol in the
DerivedTypeSpec, and collect the right one when traversing expressions
(specifically for handling initialization in module files).
Fixes https://github.com/llvm/llvm-project/issues/108827.
The missing scope information led to a crash in OpenMP semantic checks
run before printing the error that was already discovered in the code.
The following block has to be skipped for this invalid code so that we
don't emit a second spurious error.
Fixes#82913
When a function result type appears on a FUNCTION statement after some
CUDA attributes, there wasn't always valid program source location
information attached to the function result variable information stack.
Ensure that some relevant source information is always available.
Use associated procedure pointers were eliciting bogus errors from
semantics if their modules also contained generic procedure interfaces
of the same name. (The compiler handles this case correctly when the
specific procedure of the same name is not a pointer.)
With this fix, the test case in
https://github.com/llvm/llvm-project/issues/107784
no longer experiences semantic errors; however, it now crashes
unexpectedly in lowering.
The standard requires that a generic interface with the same name as a
derived type contain only functions. We generally allow a generic
interface to contain both functions and subroutines, since there's never
any ambiguity at the point of call; these is helpful when the specific
procedures of two generics are combined during USE association. Emit a
warning instead of a hard error when a generic interface with the same
name as a derived type contains a subroutine to improve portability of
code from compilers that don't check for this condition.
Don't attempt to give an object a default binding label when it shows up
in a declaration after it has already been given an explicit binding
label in an earlier declaration.
Fixes https://github.com/llvm/llvm-project/issues/106019.
Interfaces don't inherit the IMPLICIT typing rules of their enclosing
scope, and separate MODULE PROCEDUREs inherit the IMPLICIT typing rules
of submodule in which they are defined, not the rules from their
interface.
Fixes https://github.com/llvm/llvm-project/issues/102558.
The check for a structure constructor to a forward-referenced derived
type wasn't tripping for constructors in the type definition itself. Set
the forward reference flag unconditionally at the beginning of name
resolution for the type definition.
External procedures about which no characteristics are known -- from
EXTERNAL and PROCEDURE() statements of entities that are never called --
are marked as subroutines. This shouldn't be done for procedure
pointers, however.
Fixes https://github.com/llvm/llvm-project/issues/101908.
Ensure that type parameters are declared as such before being referenced
within the derived type definition. (Previously, such references would
resolve to symbols in the enclosing scope.)
This change causes the symbols for the type parameters to be created
when the TYPE statement is processed in name resolution. They are
TypeParamDetails symbols with no KIND/LEN attribute set, and they shadow
any symbols of the same name in the enclosing scope.
When the type parameter declarations are processed, the KIND/LEN
attributes are set. Any earlier reference to a type parameter with no
KIND/LEN attribute elicits an error.
Some members of TypeParamDetails have been retyped &/or renamed.
f18 current emits an error when an assignment is made to an array
section with a vector subscript, and the array is finalized with a
non-elemental final subroutine. Some other compilers emit this error
because (I think) they want variables to only be finalized in place, not
by a subroutine call involving copy-in & copy-out of the finalized
elements.
Since many other Fortran compilers can handle this case, and there's
nothing in the standards to preclude it, let's downgrade this error
message to a portability warning.
This patch got complicated because the API for the WhyNotDefinable()
utility routine was such that it would return a message only in error
cases, and there was no provision for returning non-fatal messages. It
now returns either nothing, a fatal message, or a non-fatal warning
message, and all of its call sites have been modified to cope.
Transformational functions from the intrinsic module ISO_C_BINDING are
allowed in specification expressions, so tweak some general checks that
would otherwise trigger error messages about inadmissible targets, dummy
procedures in specification expressions, and pure procedures with impure
dummy procedures.
This patch implements support for the VECTOR ALWAYS directive, which
forces
vectorization to occurr when possible regardless of a decision by the
cost
model. This is done by adding an attribute to the branch into the loop
in LLVM
to indicate that the loop should always be vectorized.
This patch only implements this directive on plan structured do loops
without labels. Support for unstructured loops and array
expressions is planned for future patches.
This CDEFINED keyword extension to a language-binding-spec signifies
that static storage for an interoperable variable will be allocated
outside of Fortran, probably by a C/C++ external object definition.
…terfaces
In "PROCEDURE(iface) :: proc", if "iface" has the BIND(C) attribute,
then so should proc, as if the declaration had been "PROCEDURE(iface),
BIND(C) :: proc". This had been working in name resolution only in cases
where "iface" had been declared before "proc".
Note that if "iface" is declared with an empty binding name
("BIND(C,NAME='')"), "proc" does not inherit that property. Use an
explicit "BIND(C,NAME='')" on the "PROCEDURE" statement for that.
This behavior is not clearly defined in the standard, but seems to match
what some other Fortran compilers do.
The code that used existing type declarations (if any) for the names
being used as dummy arguments in a statement function definition would
apply those types only if they came from EntityDetails symbols. This
broke a case in which the type was being inherited from a Cray pointee.
Fixes https://github.com/llvm/llvm-project/issues/93484.
Derived from #92480. This PR supports parsing of the DO CONCURRENT
REDUCE clause in Fortran 2023. Following the style of the OpenMP parser
in MLIR, the front end accepts both arbitrary operations and procedures
for the REDUCE clause. But later Semantics can notify type errors and
resolve procedure names.
When a symbol appears in a specification expression in a subprogram
contained in a host program unit, semantics may have to create a symbol
in the host and use host association to it. This shouldn't happen for
nested subprograms that can't import such a symbol, such as interface
blocks by default. Further, when host association fails, semantics
shouldn't crash.
Fixes https://github.com/llvm/llvm-project/issues/92647.
EQUIVALENCE set processing assumes that any arrays have explicit shape
and constant lower bounds. When an erroneous program violates those
assumptions, the compiler crashes. Fix.
Fixes https://github.com/llvm/llvm-project/issues/92636.
This is a re-worked version of #91668. It adds the `cudadevice` module
and set the `device` attributes on its functions/subroutines so there is
no need for special case in semantic check.
`cudadevice` module is implicitly USE'd in `global`/`device` subprogram.
A !$CUF KERNEL DO directive is allowed to have advisory REDUCE clauses
similar to those in OpenACC and DO CONCURRENT. Parse and represent them.
Semantic validation will follow.
When a procedure is defined with a subprogram but never referenced in a
compilation unit, it may not be characterized until lowering, and any
errors in characterization then may crash the compiler. So always ensure
that procedure definitions are characterizable in declaration checking.
Fixes https://github.com/llvm/llvm-project/issues/91845.
