The standard's specification for the ASSOCIATED() intrinsic function
describes its optional second argument (TARGET=) as being required
to be a valid target for a pointer assignment statement in which the
first argument (POINTER=) was the left-hand side. Some Fortran compilers
apparently interpret this text as a requirement that the POINTER= argument
actually be a valid left-hand side to a pointer assignment statement,
and emit an error if it is not so. This particularly affects the
use of an explicit NULL pointer as the first argument.
Such usage is well-defined, benign, useful, and supported by at least
two other compilers, so we should continue to accept it. This patch
adds a portability warning and some documentation.
In order to implement the portability warning in the best way, the
special checks on calls to the ASSOCIATED() intrinsic function have
been moved from intrinsic processing to Semantics/check-calls.cpp,
whence they have access to semantics' toolchest. Special checks for
other intrinsic functions might also migrate in the future in order
to keep them all in one place.
Differential Revision: https://reviews.llvm.org/D142768
Fix a subtle bug in procedure compatibility checking with base
derived types vs. their extensions to ensure that a procedure
expecting an extended type cannot be associated with a pointer
(or dummy procedure) to a procedure expecting a base type.
subroutine s1(base); ... subroutine s2(extended)
procedure(s1), pointer :: p
p => s2 ! <- must be caught as an error
Differential Revision: https://reviews.llvm.org/D142753
When specific procedures of a generic have dummy procedures,
underspecified actual procedures can match more than one specific
procedure. This can happen with actual procedures that are
externals with implicit interfaces, including the completely
unspecified case of a PROCEDURE() or EXTERNAL that doesn't even
differentiate between a subroutine and a function.
Generic resolution can already handle cases of ambiguous resolution
due to the use of NULL() actual arguments with no MOLD= arguments
to define their types. Extend the handling of ambiguous actual
arguments to include the case of underspecified actual procedures.
Differential Revision: https://reviews.llvm.org/D140151
Constraint C1529 requires that the base object of a type-bound procedure
reference be a scalar if the TBP has the NOPASS attribute. Most
compilers do not enforce this constraint and it does not appear to
have any implementation justification, so emit portability warning.
On the other hand, we fail to enforce C919 for references to
procedure pointer components, whose base objects must of course
be scalars in order to avoid ambiguity and empty arrays, whether
NOPASS is present or not.
Differential Revision: https://reviews.llvm.org/D140148
Impose a large but finite limit on the size of a variable being
initialized in a DATA statement to provide a readable error message
for artificial test cases that's better than a memory allocation
failure crash.
Differential Revision: https://reviews.llvm.org/D140146
In type-bound generic resolution, when the actual argument
is monomorphic, resolve the call to the target of the
most recent (i.e., least deeply inherited) override of
the binding, if any.
Differential Revision: https://reviews.llvm.org/D140127
In order to emit overflow warnings from assignment statements whose
right-hand sides are constants that undergo conversions, run the
right-hand sides of assignments through constant folding after the
conversions have been made explicit in expression analysis.
Differential Revision: https://reviews.llvm.org/D139151
Check most of the requiremens of constraint C1577 for statement functions.
The restrictions that prevent recursion are hard errors; the others seem
to be benign legacies and are caught as portability warnings.
Differential Revision: https://reviews.llvm.org/D139136
Type-bound generics like operator(+) and assignment(=) need to not be
PRIVATE if they are used outside the module in which they are declared.
Differential Revision: https://reviews.llvm.org/D139123
When checking the specific procedures of a generic interface for a
match against a given set of actual arguments, be sure to not match
a function against a subroutine call or vice versa. (We generally
catch and warn about attempts to declare mixed interfaces, but they
are usually conforming and can be inadvertently created when generics
are merged due to USE and host association.)
Differential Revision: https://reviews.llvm.org/D139059
When the left-hand side of an intrinsic assignment statement is
polymorphic, the LHS must be a whole allocatable variable or
component and may not be a coarray (10.2.2.1p1(1)).
Differential Revision: https://reviews.llvm.org/D139049
A NULL() pointer is generally not a valid expression (as opposed to
a variable) apart from some initialization contexts and some actual
arguments.
Differential Revision: https://reviews.llvm.org/D139047
The standard does *not* require that a real or imaginary part of a complex
literal constant be a scalar if it is a named constant. Downgrade a
recently installed check to a portability warning, and document it.
Differential Revision: https://reviews.llvm.org/D139046
When a scope declares the name and perhaps some characteristics of
an external subprogram using any of the many means that Fortran supplies
for doing such a thing, and that external subprogram's definition is
available, check the local declaration against the external definition.
In particular, if the global definition's interface cannot be called
by means of an implicit interface, ensure that references are via an
explicit and compatible interface.
Further, extend call site checking so that when a local declaration
exists for a known global symbol and the arguments are valid for that
local declaration, the arguments are checked against the global's
interface, just are is already done when no local declaration exists.
Differential Revision: https://reviews.llvm.org/D139042
The internal representation for array constructors in expressions during semantic
analysis needs to be able to accommodate circumstances (e.g. TRIM(), substrings)
in which the length of the elements in the array is either unknown or cannot be
represented as a context-free integer expression.
Differential Revision: https://reviews.llvm.org/D139041
Rework some recent changes to the ENUM_CLASS() macro so that
all of the construction of enumerator-to-name string mapping
data structures is again performed at compilation time.
Differential Revision: https://reviews.llvm.org/D137859
The infrastructure in semantics that is used to check that the
left-hand sides of normal assignment statements are really definable
variables was not being used to check whether the LHSs of pointer assignments
are modifiable, and so most cases of unmodifiable pointers are left
undiagnosed. Rework the semantics checking for pointer assignments,
NULLIFY statements, pointer dummy arguments, &c. so that cases of
unmodifiable pointers are properly caught. This has been done
by extracting all the various definability checking code that has
been implemented for different contexts in Fortran into one new
facility.
The new consolidated definability checking code returns messages
meant to be attached as "because: " explanations to context-dependent
errors like "left-hand side of assignment is not definable".
These new error message texts and their attached explanations
affect many existing tests, which have been updated. The testing
infrastructure was extended by another patch to properly compare
warnings and explanatory messages, which had been ignored until
recently.
Differential Revision: https://reviews.llvm.org/D136979
The common language extension that allows arbitary expressions
to be used as components in a complex constructor (x,y) -- not both
constant, since that would make it a complex literal constant --
still have to be scalar; it's not an elemental operation like the
CMPLX() intrinsic function is.
Differential Revision: https://reviews.llvm.org/D136978
Broaden the check for misuse of ABSTRACT procedure interfaces by
doing it in expression analysis rather than name resolution so that
cases like pointer assignment targets and actual arguments are also
diagnosed as errors.
Differential Revision: https://reviews.llvm.org/D136971
Ensure that the semantic error "An allocatable or pointer component
reference must be applied to a scalar base" is emitted with a source
code location.
Differential Revision: https://reviews.llvm.org/D135215
When a scalar expression is not expandable -- i.e., it would have to be
evaluated once and saved in a temporary to avoid changing the semantics
of the program if it were to be evaluated more than once -- it affects
some aspects of folding and expression semantics. In cases where
scalar expansion would not cause multiple evaluations due to the shape
of the result having but a single element, however, these "non-expandable"
scalar expressions can be safely allowed.
Differential Revision: https://reviews.llvm.org/D134476
Emit a "Assignment to procedure 'foo' is not allowed" error message
for more cases of 'foo' than just declaraed subprograms, rather than
assuming that those additional cases were named constants.
Differential Revision: https://reviews.llvm.org/D132165
Assignment statements need to check for array shape conformance
errors that are discernable at compilation time.
Differential Revision: https://reviews.llvm.org/D132161
Inaccessible components -- those declared PRIVATE in another module -- should
be allowed to be redeclared in extended types, and should be ignored if
they appear as keywords in structure constructors.
Differential Revision: https://reviews.llvm.org/D131102
F18 disallows function references and coarray references from
appearing in scalar expressions that are to be expanded into
arrays to conform with other operands or actual arguments in
an elemental expression. This is too strong, as pure procedures
can be safely used.
Differential Revision: https://reviews.llvm.org/D131096
This patch fixes:
llvm-project/flang/lib/Semantics/expression.cpp:405:12: error:
moving a local object in a return statement prevents copy elision
[-Werror,-Wpessimizing-move]
A type-param-inquiry of %KIND or %LEN applies to a designator, and
so must also be allowed for a substring. F18 presently (mis)parses
instances of a type-param-inquiry as structure component references
and then fixes them in expression semantics when types are known and
we can distinguish them. But when the base of a type-param-inquiry is
a substring of an array element, as in "charArray(i)(j:k)%len",
parsing fails.
Adjust the grammar to parse these cases, and extend expression semantics
to process the new production.
Differential Revision: https://reviews.llvm.org/D130375
Create a TargetCharacteristics class to centralize the few items of
target specific information that are relevant to semantics. Use the
new class for all target queries, including derived type component layout
modeling.
Future work will initialize this class with target information
provided or forwarded by the drivers, and use it to fold layout-dependent
intrinsic functions like TRANSFER().
Differential Revision: https://reviews.llvm.org/D129018
Updates: Attempts to work around build issues on Windows.
When generic resolution finds its specific procedure in a module,
and that specific procedure is not use-associated into the local scope
(perhaps because it was PRIVATE, perhaps because the generic was
use-associated with ONLY:), we create a new use-association with
a renaming. The name constructed for this renaming needs to be
additionally qualified with the module name of the specific procedure
in order to avoid clashing with another specific of the same name
that may have previously been use-associated in the same way from
a distinct module.
Differential Revision: https://reviews.llvm.org/D127790
The previous semantic analysis does not consider when the last part-ref
is scalar or complex part. Refactor the previous code and bring all the
checks into one place. The check starts from the designator by
extracting the dataref wrapped including the substring and complex part
and recursively check the base objects.
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D126595
As an extension for REAL literals, we allow an exponent letter which
matches an explicit kind-param. The standard requires the exponent
to be 'E' if a kind-param is present. This patch
- documents this extension in Extensions.md
- enables a portability warning if it is used with -pedantic
The test case for this, kinds05.f90, needs D125804, which makes
test_errors.py test warnings as well, to actually test the warnings.
I include it already now to keep things together, it will do no harm
(I hope ...).
We also add WARNING-directives to the test kinds04.f90 in preparation
for D125804. As the exponent-letter 'Q' does not imply the same kind
on all platforms, the emitted warnings are platform-dependent.
Therefore, the test is duplicated into two variants which are run
conditionally.
Finally, we promote the portability warning for when the exponent letter
is neither 'E' nor matching the kind-param to a standard warning.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D126459
When two or more generic interfaces are available by declaration or
by USE association at different scoping levels, we need to search
the outer generic interfaces as well as the inner ones, but only after
the inner ones have failed to produce a specific procedure that matches
a given set of actual arguments. This means that it is possible for
a specific procedure of a generic interface of an inner scope to override
a conflicting specific procedure of a generic interface of an outer
scope.
Also cope with forward references to derived types when a generic
interface is also in scope.
Fixes LLVM bug https://github.com/llvm/llvm-project/issues/55240 and
LLVM bug https://github.com/llvm/llvm-project/issues/55300.
Differential Revision: https://reviews.llvm.org/D126587
When processing the literal constants of the various kinds of
INTEGER that are too large by 1 (e.g., 2147483648_4) in expression
analysis, emit a portability warning rather than a fatal error if
the literal constant appears as the operand to a unary minus, since
the folded result will be in range. And don't emit any warning if
the negated literal is coming from a module file -- f18 wrote the
module file and the warning would simply be confusing, especially to
the programmer that wrote (-2147483647_4-1) in the first place.
Further, emit portability warnings for the canonical expressions for
infinities and NaN (-1./0., 0./0., & 1./0.), but not when they appear
in a module file, for the same reason. The Fortran language has no
syntax for these special values so we have to emit expressions that
fold to them.
Fixes LLVM bugs https://github.com/llvm/llvm-project/issues/55086 and
https://github.com/llvm/llvm-project/issues/55081.
Differential Revision: https://reviews.llvm.org/D126584
A recent fix beefed up semantics checking to catch the case of a call
to an external assumed-length character function; this check has false
positives in the case of an assumed-length character function that is
a dummy procedure. These do have a length that is passed in extra
compiler-created arguments. This patch refines the check and undoes some
changes to tests.
Differential Revision: https://reviews.llvm.org/D126390
The purity or impurity of a call to a generic interface
depends on the attributes of the specific procedure or specific
binding. Change expression analysis of calls to generic interfaces
to replace the symbol in the parse tree with the specific procedure
or binding; this ensures that later checking for purity in
DO CONCURRENT and other contexts will be accurate.
Remove an "XFAIL" from a test that now passes again with this fix.
Differential Revision: https://reviews.llvm.org/D126150
Semantics was allowing calls to CHARACTER(*) functions, which are odd
things -- they can be declared, and passed around, but can never actually
be called as such. They must be redeclared with an explicit length that
ends up being passed as a hidden argument. So check for these calls
and diagnose them, add tests, and clean up some existing tests that
were in error and now get caught.
Possible TODO for lowering: there were some test cases that used
bad calls to assumed-length CHARACTER*(*) functions and validated
their implementations. I've removed some, and adjusted another,
but the code that somehow implemented these calls may need to be
removed and replaced with an assert about bad semantics.
Differential Revision: https://reviews.llvm.org/D126148
Complex component references (z%RE, z%IM) of complex named constants
should be evaluated at compilation time.
Differential Revision: https://reviews.llvm.org/D125341
When resolving a procedure reference, do not allow a successful
intrinsic procedure probe result to override an existing
symbol.
Differential Revision: https://reviews.llvm.org/D123905
Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.
This change is enabled only for GCC builds with GCC >= 9;
an earlier attempt (D122441) ran into bugs in some versions of
clang and was reverted rather than simply disabled; and it is
not well tested with MSVC. In non-GCC and older GCC builds,
common::visit() is simply an alias for std::visit().
The x%KIND inquiry needs to be supported when 'x' is itself
a complex part reference or a type parameter inquiry.
Differential Revision: https://reviews.llvm.org/D123733
For parameterized derived type component initializers whose
expressions' types depend on parameter values, f18's current
scheme of analyzing the initialization expression once during
name resolution fails. For example,
type :: pdt(k)
integer, kind :: k
real :: component = real(0.0, kind=k)
end type
To handle such cases, it is necessary to re-analyze the parse
trees of these initialization expressions once for each distinct
initialization of the type.
This patch adds code to wipe an expression parse tree of its
typed expressions, and update those of its symbol table pointers
that reference type parameters, and then re-analyze that parse
tree to generate the properly typed component initializers.
Differential Revision: https://reviews.llvm.org/D123728
Fortran allows a generic interface to have he same name as an
intrinsic procedure. If the intrinsic is explicitly marked with
the INTRINSIC attribute, restrictions apply (C848) - the generic
must contain only functions or subroutines, depending on the
intrinsic. Explicit or not, the generic overrides the intrinsic,
but the intrinsic behavior must still be available for calls
whose actual arguments do not match any of the specific procedures.
Semantics was not checking constraint C848, and it didn't allow
an explicit INTRINSIC attribute on a name of a generic interface.
Differential Revision: https://reviews.llvm.org/D123713
Error messages can have a list of attachments; these are used to point
to related source locations, supply additional information, and to
encapsulate error messages that were *not* emitted in a given context
to explain why a warning was justified.
This patch adds a message severity ("Because") for that last case,
and extends to AttachTo() API to provide a means for overriding
the severity of an attached message.
Some existing message attachments had their severities adjusted,
now that we're printing them. And operator==() for Message was
cleaned up while debugging after I noticed that it was recursively
O(N**2) and subject to returning a false positive.
Differential Revision: https://reviews.llvm.org/D123710
