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.
Some functions and subroutines are available in device context
(device/global). These functions have interfaces declared in the
`cudadevice` module.
This patch adds interfaces as `__cuda_device_builtins_<fctname>` in a
builtin module and they are USE'd rename in the `cudadevice` module. The
module is implicitly used in device/global subprograms.
The builtin module only contains procedures from section 3.6.4 for now.
There are two constraints in the language that prohibit the use of an
ENTRY name being used as the RESULT() variable of the function or
another ENTRY name in the same function's scope; neither can the name of
the function be used as the RESULT() of an ENTRY.
Move most of the existing partial enforcement of these constraints from
name resolution into declaration checking, complete it, and add more
cases to the tests.
Fortran has an ambiguously defined rule about the typing of index
variables of implied DO loops in DATA statements and array constructors
that omit an explicit type specification. Such indices have the type
that they would have "if they were variables" in the innermost enclosing
scope. Although this could, and perhaps should, be read to mean that
implicit typing rules active in that innermost enclosing scope should be
applied, every other Fortran compiler interprets that language to mean
that if there is a type declaration for that name that is visible from
the enclosing scope, it is applied, and it is an error if that type is
not integer.
Fixes https://github.com/llvm/llvm-project/issues/91053.
As the kinds of the integer types of type parameters may well depend on
the values of other type parameters, defer the attempt to convert their
values to the point of type instantiation instead of doing it during
declaration processing.
…Warn()
Many warning messages were being emitted unconditionally. Ensure that
all warnings are conditional on a true result from a call to
common::LanguageFeatureControl::ShouldWarn() so that it is easy for a
driver to disable them all, or, in the future, to provide per-warning
control over them.
…grams
The parser only recognizes compiler directives that appear within
internal / module subprograms, not those that might appear between them.
Extend to allow them between subprograms as well.
When a statement function in a nested scope has a name that clashes with
a name that exists in the host scope, the compiler can handle it
correctly (with a portability warning)... unless the host scope acquired
the name via USE association. Fix.
Fixes https://github.com/llvm/llvm-project/issues/88678.
When a symbol is known to be a procedure due to its being referenced as
a function or subroutine, improve the error messages that appear if the
symbol is also used as an object by attaching the source location of its
procedural use. Also, for errors spotted in name resolution due to how a
given symbol has been used, don't unconditionally set the symbol's error
flag (which is otherwise generally a good idea, to prevent cascades of
errors), so that more unrelated errors related to usage will appear.
Address TODOs in the intrinsic module ISO_FORTRAN_ENV, and extend the
implementation of NUMERIC_STORAGE_SIZE so that the calculation of its
value is deferred until it is needed so that the effects of
-fdefault-integer-8 or -fdefault-real-8 are reflected. Emit a warning
when NUMERIC_STORAGE_SIZE is used from the module file and the default
integer and real sizes do not match.
Fixes https://github.com/llvm/llvm-project/issues/87476.
When a program attempts to use a non-object entity as the base of a
component reference or type parameter inquiry, the message is somewhat
uninformative and the position of the entity's declaration will not
reflect any updates made to the symbol during name resolution.
Includes some NFC C++17 style clean-up on some code noticed while
debugging (missing mandatory braces).
A derived type name in an IMPLICIT statement might be a host association
or it might be a forward reference to a local derived type, which may be
shadowing a host-associated name. Add a scan over the specification part
in search of derived type definitions to determine the right
interpretation.
Fixes https://github.com/llvm/llvm-project/issues/87215.
Fortran allows the INTRINSIC attribute to be specified with a distinct
attribute statement, and also as part of the attribute list of a
type-declaration-stmt. This is an odd case (especially as the declared
type is mandated to be ignored if it doesn't match the type of the
intrinsic function) that can lead to odd error messages and crashes,
since the rest of name resolution expects that intrinsics with explicit
declarations will have been declared with INTRINSIC attribute
statements. Resolve by handling an "inline" INTRINSIC attribute as a
special case while processing a type-declaration-stmt, so that
real, intrinsic :: acos, asin, atan
is processed exactly as if it had been
intrinsic acos, asin, atan; real acos, asin, atan
Fixes https://github.com/llvm/llvm-project/issues/86382.
ConvertToObjectEntity() returns true for use- and host-associated object
symbols, too. Ensure in this case that the symbol really is a
non-associated object.
Fixes https://github.com/llvm/llvm-project/issues/85776.
…d type
When the same name is used for a derived type and generic interface in a
module, and no explicit PUBLIC or PRIVATE statement appears for the name
but the derived type definition does have an explicit accessibility,
that accessibility must also apply to the generic interface.
Save both the raw procedure interface symbol as well as the result of
passing it through GetUltimate() and BypassGeneric() in symbol table
entries with ProcEntityDetails. The raw symbol of the interface needs to
be the one used for emitting procedure symbols to module files.
Fixes https://github.com/llvm/llvm-project/issues/83836.
…ines
Name resolution needs to delay its default determination of module
external procedures as subroutines until after it has skimmed the
execution parts of module procedures.
Fixes https://github.com/llvm/llvm-project/issues/83622.
It's probably a bad idea to have a Cray pointer whose type is a derived
type that is not a sequence type, but the feature is a nonstandard
extension in the first place. Downgrade the message to a warning.
Fixes https://github.com/llvm/llvm-project/issues/82210.
Use BypassGeneric() to process the name of an interface in a procedure
declaration statement, so that if it's the name of a generic with a
homonymous specific procedure, that's what defines the interface.
Fixes https://github.com/llvm/llvm-project/issues/82267.
Fortran allows a procedure declaration statement with no interface or
type, with an explicit type declaration statement elsewhere being used
to define a function's result.
Fixes https://github.com/llvm/llvm-project/issues/82006.
When DATA statement objects have derived types obtained by implicit
typing rules, their types aren't known until specification part
processing is complete. In the case of a derived type, any component
name in a designator may still be in need of name resolution. Take care
of it in the deferred check visitor that runs at the end of name
resolution in each specification and execution part.
Fixes https://github.com/llvm/llvm-project/issues/82069.
…istinguishing characteristic
We note whether a procedure's interface is explicit or implicit as an
attribute of its characteristics, so that other semantics can be checked
appropriately, but this internal attribute should not be used as a
distinguishing characteristic in itself.
Fixes https://github.com/llvm/llvm-project/issues/81876.
When statement function expressions are analyzed, ensure that the
semantics context has a valid location set, otherwise a type spec (like
"integer::") can lead to a crash.
Fixes https://github.com/llvm/llvm-project/issues/80532.
When a separate module procedure is defined with a MODULE PROCEDURE and
its corresponding interface has a binding label, the compiler was
emitting an error about mismatching binding labels because the binding
label wasn't being copied into the subprogram's definition.
