Support the names AND, OR, and XOR for the generic intrinsic
functions IAND, IOR, and IEOR respectively.
Differential Revision: https://reviews.llvm.org/D122034
Interfaces which are internal to a procedure need to be included in
module files if (and only if) they are referenced in the interface of
the procedure. That is, they are needed if they are the interfaces of
dummy or return value procedures.
Fixes#53420
Differential Revision: https://reviews.llvm.org/D121738
evaluate::IsPointerObject used to return true for pointer suboject like
`pointer(10)` while these object are not pointers. This prevented some
checks like 15.5.2.7 to be correctly enforced (e.g., it was possible to
pass `pointer(10)` to a non intent(in) dummy pointer).
After updating IsPointerObject behavior and adding a test for 15.5.2.7 in
call07.f90, a test in call03.f90 for 15.5.2.4(14) was failing.
It appeared the related semantics check was relying on IsPointerObject
to return true for `pointer(10)`. Adapt the code to detect pointer element
in another way.
While looking at the code, I also noticed that semantics was
rejecting `character(1)` pointer/assumed shape suboject when these are
allowed (the standard has a special case for character(1) in
15.5.2.4(14), and I verified that other compilers that enforce 15.5.2.4(14)
do accept this).
Differential Revision: https://reviews.llvm.org/D121377
Using recently established message severity codes, upgrade
non-fatal messages to usage and portability warnings as
appropriate.
Differential Revision: https://reviews.llvm.org/D121246
When a module uses a derived type that is shadowed by a generic
interface, the module file was missing a USE statement for the
name. Detect and handle this situation.
Differential Revision: https://reviews.llvm.org/D121160
When a structure constructor does not initialize an allocatable component,
ensure that the typed expression representation contains an explicit
NULL() for the component. Expression semantics already copies default
initialized expressions for nonallocatable components into structure
constructors. This change is expected to simplify lowering.
Differential Revision: https://reviews.llvm.org/D121162
This patches modifies PDT runtime type info generation so that it is
easier to handle derived type descriptor in lowering. It changes three
aspects:
1. The symbol name suffix of runtime type info for PDT instantiation is
changed from a serial number unrelated to the types to an encoding of
the instantiated KIND parameters.
2. New runtime type info is not created for each instantiation of PDT without
KIND parameters (only length parameters). Instead, the runtime type
info of the type definition is always used. It is updated to contain
the component descriptions.
3. Runtime type info of PDT instantiation is now always generated in the
scope where the type is defined. If several PDT type instantiation
are made in different scope with the same kind parameters, they will
use the same runtime type info.
Rational of the change:
In lowering, derived type descriptors are not mapped when instantiating derived
type objects. They are mapped later when symbol knowledge is not available anymore.
This mapping is based on the FIR representation of derived types. For
PDT, the FIR type information does not allow deducing the instantiation
scope, it only allows retrieving the type name, the type _definition_
scope, and the kind parameter values. Therefore, in order to be able to
retrieve the derived type descriptor from a FIR type, the derived type
descriptor must be generated in the definition scope and must reflect
the kind parameters. This justifies the need for changes 1. and 3.
above (suffix and scope change). Changes 2. comes from the fact that
all runtime type info of type without kind parameters can be generated
from the type definition, and that because of the suffix change, the
symbol name for type definition and type instantiation are the same.
Although this change is first motivated by how lowering handles derived
types, I believe it is also an improvement from a functional point of
view since this change will allow reducing the number of generated
runtime type info for PDTs, since redundant information (different
instantiations with same kind parameters) will only be generated once.
Differential Revision: https://reviews.llvm.org/D120801
Add new IsCompatibleWith() member functions to many classes in evaluate::characteristics
that apply more nuanced compatibility checking for function results, dummy
arguments, and procedure interfaces than the previous tests for complete
equivalence. Use IsCompatibleWith() in semantics for call checking.
Differential Revision: https://reviews.llvm.org/D120844
The symbol table, name resolution, and semantic checks for module
subprograms -- esp. for MODULE FUNCTION and MODULE SUBROUTINE, but
also MODULE PROCEDURE -- essentially assumed that the subprogram
would be defined in a submodule of the (sub)module containing its
interface. However, it is conforming to instead declare a module
subprogram in the *same* (sub)module as its interface, and we need
to handle that case.
Since this case involves two symbols in the same scope with the same
name, the symbol table details for subprograms have been extended
with a pointer to the original module interface, rather than relying
on searching in scopes.
Differential Revision: https://reviews.llvm.org/D120839
Name resolution was properly probing the table of unrestricted
specific intrinsics to find "abs", but failing to capture the
result type and save it in the created symbol table entry.
Differential Revision: https://reviews.llvm.org/D120749
An assumed-type actual argument that corresponds to an assumed-rank dummy
argument shall be assumed-shape or assumed-rank.
Differential Revision: https://reviews.llvm.org/D120750
Derived types with allocatable and pointer components cannot
be used in I/O data transfer statements unless they have defined
I/O procedures available (as type-bound or regular generics).
These cases are caught as errors by the I/O runtime library,
but it would be better if they were flagged during compilation.
(Address comment in review: don't use explicit name string lengths.)
Differential Revision: https://reviews.llvm.org/D120675
Test a range of acceptable forms of SYNC TEAM statements,
including combinations with and without the stat-variable
and errmsg-variable present. Also test that several invalid
forms of SYNC TEAM call generate the correct error messages.
Differential Revision: https://reviews.llvm.org/D120099
Test a range of acceptable forms of SYNC MEMORY statements,
including combinations with and without the stat-variable
and errmsg-variable present. Also test that several invalid
forms of SYNC MEMORY call generate the correct error messages.
Differential Revision: https://reviews.llvm.org/D120097
Test a range of acceptable forms of SYNC IMAGES statements,
including combinations with and without the stat-variable
and errmsg-variable present. Also test that several invalid
forms of SYNC IMAGES call generate the correct error messages.
Differential Revision: https://reviews.llvm.org/D118933
Test a range of acceptable forms of SYNC ALL statements,
including combinations with and without the stat-variable
and errmsg-variable present. Also test that several invalid
forms of SYNC ALL call generate the correct error messages.
Differential Revision: https://reviews.llvm.org/D114181
The fortran standard views blanks in IO formats as white space in
non-string contexts. Other compilers extend this to also view horizontal
tabs as white space. Some compilers additionally add other white space
characters to this group.
Add recognition of horizontal and vertical tabs to runtime format
validation code to match what the runtime code currently does.
Calls to C_F_POINTER() without the optional SHAPE= third argument
were failing to be recognized as proper calls to the intrinsic,
but the failure was not generating any error message. This led to
a crash in lowering, which rightfully expects a typed expression
to be associated with the call.
So (1) catch silent failures to convert CALL statements as internal
errors, as is done for expressions and assignment statements; and
(2) clean up C_F_POINTER intrinsic handling to cope with only two
arguments and to emit an error for a FPTR= argument with no type.
Differential Revision: https://reviews.llvm.org/D119847
EQUIVALENCE storage association of objects whose types are not
both default-kind numeric storage sequences, or not both default-kind
character storage sequences, are not standard conformant.
However, most Fortran compilers admit such usage, with warnings
in strict conformance mode. This patch allos EQUIVALENCE of objects
that have sequence types that are either identical, both numeric
sequences (of default kind or not), or both character sequences.
Non-sequence types, and sequences types that are not homogeneously
numeric or character, remain errors.
Differential Revision: https://reviews.llvm.org/D119848
When a pointer assignment with bounds remapping has a function
reference as its right-hand side, don't check for array conformance.
Differential Revision: https://reviews.llvm.org/D119845
Semantic analysis was emitting a bogus error message when a structure
constructor contains a monomorphic value for a (limited) polymorphic
component of a derived type. The type compatibility test was too
strict; this patch relaxes it a little to allow values that could
be assigned or passed to a variable or dummy argument with that type.
Also add some quotes to an error message that was sometimes confusing
without them, and remove a repeated space character from another.
Differential Revision: https://reviews.llvm.org/D119744
While one cannot of course statically initialize an allocatable component
of an instance of a derived type, its mere presence should not prevent
DATA initialization of the other nonallocatable components. Semantics
was treating the existence of an allocatable component as a case of
"default initialization", which it is, but not one that should run
afoul of C877. Add another Boolean argument to IsInitialized() to allow
for a more nuanced test.
Differential Revision: https://reviews.llvm.org/D119449
Currently, code generation was creating weak symbols for derived type
descriptor global it could not find in the current compilation unit.
The rational is that:
- the derived type descriptors of external module derived types are
generated in the compilation unit that compiled the module so that
the type descriptor address is uniquely associated with the type.
- some types do not have derived type descriptors: the builtin derived
types used to create derived type descriptors. The runtime knows
about them and does not need them to accomplish the feat of
describing themselves. Hence, all unresolved derived type descriptors
in codegen cannot be assumed to be resolved at link time.
However, this caused immense debugging pain when, for some reasons, derived
type descriptor that should be generated were not. This caused random
runtime failures instead of a much cleaner link time failure.
Improve this situation by allowing codegen to detect the builtin derived
types that have no derived type descriptors and requiring the other
unresolved derived type descriptor to be resolved at link time.
Also make derived type descriptor constant data since this was a TODO
and makes the situation even cleaner. This requiring telling lowering
which compiler created symbols can be placed in read only memory. I
considered using PARAMETER, but I have mixed feeling using it since that
would cause the initializer expressions of derived type descriptor to
be invalid from a Fortran point of view since pointer targets cannot be
parameters. I do not want to start misusing Fortran attributes, even if
I think it is quite unlikely semantics would currently complain. I also
do not want to rely on the fact that all object symbols with the
CompilerCreated flags are currently constant data. This could easily
change in the future and cause runtime bugs if lowering rely on this
while the assumption is not loud and clear in semantics.
Instead, add a ReadOnly symbol flag to tell lowering that a compiler
generated symbol can be placed in read only memory.
Differential Revision: https://reviews.llvm.org/D119555
Device clause when it occurs with **target enter data** and **target exit data** must be declared with some non negative value. So some changes were made to evaluate the device clause argument to non negative value and throw the expected error when it takes negative value as argument.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D119141
It is generally an error when a USE-associated name clashes
with a name defined locally, but not in all cases; a generic
interface can be both USE-associated and locally defined.
This works, but not when there is also a local subprogram
with the same name, which is valid when that subprogram is
a specific of the local generic. A bogus error issues at
the point of the USE because name resolution will have already
defined a symbol for the local subprogram.
The solution is to collect the names of local generics when
creating the program tree, and then create their symbols as
well if their names are also local subprograms, prior to any
USE association processing.
Differential Revision: https://reviews.llvm.org/D119566
When a scope's symbol has characteriztics whose specification
expressions depend on other non-constant symbols in the same scope,
f18 rightfully emits an error. However, in the case of usage in
specification expressions involving host association, the program is not
invalid. This can arise, for example, in the case of an internal
function whose result's attributes use host-associated variables.
Differential Revision: https://reviews.llvm.org/D119565
There are several checks in the runtime routine for the RESHAPE
intrinsic. Some checks verify things that should have been checked at
compile time while others represent user errors.
This update changes the checks for user errors into calls to "Crash"
which include information about the failing check. This identifies them
as user errors rather than compiler errors.
I also verified that the checks that remain as internal errors are also
checked by the front end. I added a test to the front end's RESHAPE
test to complete the checks.
Differential Revision: https://reviews.llvm.org/D119596
Section 10.2.2.4, paragraph 3 states that a procedure pointer with an explicit
interface must have the same characteristics as its target. Previously, we
interpreted this as disallowing such pointers to point to procedures with
implicit interfaces. But several other compilers allow this.
We make an exception for the case where the explicit interface cannot be
called via an implicit interface.
This change makes us allow this, also
Differential Revision: https://reviews.llvm.org/D119404
The second argument to the ASSOCIATED intrinsic must be a valid pointer
or target. The test for this property only checked the last symbol
in a data-reference, but any symbol in the reference with the
POINTER or TARGET attribute will do.
Differential Revision: https://reviews.llvm.org/D119450
Fortran allows forward references to derived types, including
function results that are typed in a prefix of a FUNCTION statement.
If a type is defined in the body of the function, a reference to
that type from a prefix on the FUNCTION statement must resolve to
the local symbol, even and especially when that type shadows one
from the host scope.
The solution is to defer the processing of that type until the
end of the function's specification part. But the language doesn't
allow for forward references to other names in the prefix, so defer
the processing of the type only when it is not an intrinsic type.
The data structures in name resolution that track this information
for functions needed to become a stack in order to make this work,
since functions can contain interfaces that are functions.
Differential Revision: https://reviews.llvm.org/D119448
Previously, when calling a procedure implicitly for which a global scope
procedure symbol with the same name existed, semantics resolved the
procedure name in the call to the global symbol without checking that
the symbol interface was compatible with the implicit interface of the
call.
This could cause expression rewrite and lowering to later badly process
the implicit call assuming a different result type or an explicit
interface. This could lead to lowering crash in case the actual argument
were incompatible with the dummies from the explicit interface.
Emit errors in the following problematic cases:
- If the result type from the symbol did not match the one from the
implicit interface.
- If the symbol requires an explicit interface.
This patch still allows calling an F77 like procedure with different
actual argument types than the one it was defined with because it is
correctly supported in lowering and is a feature in some program
(it is a pointer cast). The two cases that won't be accepted have
little chance to make much sense. Results returning ABIs may differ
depending on the return types, and function that requires explicit
interface usually requires descriptors or specific processing that
is incompatible with implicit interfaces.
Note that this patch is not making a deep analysis, and it will only
catch mistakes if a global symbol and an implicit interface are
involved. Cases where the user provided a conflicting explicit
interface would still require a pass after name resolution to study
conflicts more deeply. But these cases will not crash lowering or
trigger expression rewrite to do weird things.
Differential Revision: https://reviews.llvm.org/D119274
Test a range of acceptable forms of co_broadcast calls, including
combinations of keyword and non-keyword actual arguments of
intrinsic and derived type. Also test that several invalid forms
of co_sum call generate the correct error messages.
Reviewed By: ktras
Differential Revision: https://reviews.llvm.org/D113084
When a scope uses an explicit IMPORT statement to import a
symbol from the scope's host, it should not emit a bogus error
message later if that symbol is used in a specification construct.
The code that checks for imports being hidden by local declarations
was not allowing for the presence of host association (or USE)
indirection symbols in the local scope. Fix by using GetUltimate()
before checking for the hidden symbol.
Differential Revision: https://reviews.llvm.org/D118747
For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both kinds with the same name to be used in
the same source file (but not in the same scoping unit, a
constraint of the standard that is now enforced).
The symbol table's scope tree now has a single instance of
a scope with a new kind, IntrinsicModules, whose children are
the USE'd intrinsic modules (explicit or not). This separate
"top-level" scope is a child of the single global scope and
it allows both intrinsic and non-intrinsic modules of the same
name to exist in the symbol table. Intrinsic modules' scopes'
symbols now have the INTRINSIC attribute set.
The search path directories need to make a distinction between
regular directories and the one(s) that point(s) to intrinsic
modules. I allow for multiple intrinsic module directories in
the second search path, although only one is needed today.
Differential Revision: https://reviews.llvm.org/D118631
Accept any keyword argument names of the form "An" for
values of n >= 3 in calls to the intrinsic functions MAX, MIN,
and their variants, so long as "n" has no leading zero and
all the keywords are distinct. Previously, f18 was needlessly
requiring the names to be contiguous. When synthesizing keywords
to characterize the procedure's interface, don't conflict with
the program's keywords.
Differential Revision: https://reviews.llvm.org/D117701
Consistent with previously documented policy, in which
BOZ literals are accepted in non-standard-conforming circumstances
where they can be converted to an unambiguous known numeric type,
allow BOZ literals to be passed as an actual argument in a reference
to a procedure whose explicit interface has a corresponding dummy
argument with a numeric type to which the BOZ literal may be
converted. Improve error messages associated with BOZ literal
actual arguments, too: don't emit multiple errors.
Differential Revision: https://reviews.llvm.org/D117698
When variable with the SAVE attribute appears in a pure subprogram,
emit a more specialized error message if the SAVE attribute was acquired
from static initialization.
Differential Revision: https://reviews.llvm.org/D117699
Subclause 7.5.2.4 lists conditions under which two distinct derived
types are to be considered the same type for purposes of argument
association, assignment, and so on. These conditions are implemented
in evaluate::IsTkCompatibleWith(), but assignment semantics doesn't
use it for testing for intrinsic assignment compatibility. Fix that.
Differential Revision: https://reviews.llvm.org/D117621
When a scalar-valued function with no distinct RESULT
is being called recursively in its own executable part,
emit a better message about the error. Clean up the
code that resolves function vs. array ambiguities in
expression semantics.
Update to address review comment
Differential Revision: https://reviews.llvm.org/D117577
ENTRY statement names in module subprograms were not acceptable for
use as a "module procedure" in a generic interface, but should be.
ENTRY statements need to have symbols with place-holding
SubprogramNameDetails created for them in order to be visible in
generic interfaces. Those symbols are created from the "program
tree" data structure. This patch adds ENTRY statement names to the
program tree data structure and uses them to generate SubprogramNameDetails
symbols.
Differential Revision: https://reviews.llvm.org/D117345
Very old (pre-'77 standard) codes would use arrays initialized
with Hollerith literals, typically in DATA, as modifiable
formats.
Differential Revision: https://reviews.llvm.org/D117344
Derived types with SEQUENCE must have data components of sequence
types; but this rule is relaxed as common an extension in the case of
pointer components, whose targets' types are not really relevant
to the implementation requirements of sequence types.
Differential Revision: https://reviews.llvm.org/D117158
It's not conforming to specify the SAVE attribute more than
once for a variable, but it also doesn't hurt anything and
isn't fatal in other Fortran compilers. Downgrade the
message to a warning for better portability.
Differential Revision: https://reviews.llvm.org/D117153
This is nonconformant usage, but widely accepted as an extension.
Downgrade the error message to a warning.
Differential Revision: https://reviews.llvm.org/D117152
We already accept assignments of INTEGER to LOGICAL (& vice versa)
as an extension, but not initialization. Extend initialization
to cover those cases.
(Also fix misspelling in nearby comment as suggested by code reviewer.)
Decouple an inadvertent dependence cycle by moving two
one-line function definitions into a header file.
Differential Revision: https://reviews.llvm.org/D117159
Implements part of the legacy "DEC structures" feature from
VMS Fortran. STRUCTUREs are processed as if they were derived
types with SEQUENCE. DATA-like object entity initialization
is supported as well (e.g., INTEGER FOO/666/) since it was used
for default component initialization in structures. Anonymous
components (named %FILL) are also supported.
These features, and UNION/MAP, were already being parsed.
An omission in the collection of structure field names in the
case of nested structures with entity declarations was fixed
in the parser.
Structures are supported in modules, but this is mostly for
testing purposes. The names of fields in structures accessed
via USE association cannot appear with dot notation in client
code (at least not yet). DEC structures antedate Fortran 90,
so their actual use in applications should not involve modules.
This patch does not implement UNION/MAP, since that feature
would impose difficulties later in lowering them to MLIR types.
In the meantime, if they appear, semantics will issue a
"not yet implemented" error message.
Differential Revision: https://reviews.llvm.org/D117151
A bogus error message is appearing for structure constructors containing
values that correspond to unlimited polymorphic allocatable components.
A value of any type can actually be used.
Differential Revision: https://reviews.llvm.org/D117154
This supports the following checks for THREADPRIVATE Directive:
```
[5.1] 2.21.2 THREADPRIVATE Directive
A threadprivate variable must not appear in any clause except the
copyin, copyprivate, schedule, num_threads, thread_limit, and if clauses.
```
This supports the following checks for DECLARE TARGET Directive:
```
[5.1] 2.14.7 Declare Target Directive
A threadprivate variable cannot appear in the directive.
```
Besides, procedure name and the entity with PARAMETER attribute cannot
be in the threadprivate directive. The main program name and module name
cannot be in the threadprivate directive and declare target directive.
There is no clear description or restriction about the entity with
PARAMETER attribute in OpenMP 5.1 Specification, and a warning is given.
Reviewed By: kiranchandramohan, shraiysh, NimishMishra
Differential Revision: https://reviews.llvm.org/D114941
