F'2023 7.8 para 5 requires that an implied DO loop with no iterations
in a character array constructor should have items whose lengths are
constant expressions independent of the value of the implied DO loop
index.
Differential Revision: https://reviews.llvm.org/D155968
When searching for a matching specific procedure for a set of actual
arguments in a type-bound generic interface for a defined operator,
don't discard any error messages that may have been produced for
the specific that was found. Tweak the code to preserve those
messages and add them to the context's messages, and add a test.
Differential Revision: https://reviews.llvm.org/D155966
Begin upstreaming of CUDA Fortran support in LLVM Flang.
This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature enum value for CUDA Fortran
- driver change to enable that feature for *.cuf and *.CUF source files
- parse tree representation of CUDA Fortran syntax
- dumping and unparsing of the parse tree
- the actual parsers for CUDA Fortran syntax
- prescanning support for !@CUF and !$CUF
- basic sanity testing via unparsing and parse tree dumps
... along with any minimized changes elsewhere to make these
work, mostly no-op cases in common::visitors instances in
semantics and lowering to allow them to compile in the face
of new types in variant<> instances in the parse tree.
Because CUDA Fortran allows the kernel launch chevron syntax
("call foo<<<blocks, threads>>>()") only on CALL statements and
not on function references, the parse tree nodes for CallStmt,
FunctionReference, and their shared Call were rearranged a bit;
this caused a fair amount of one-line changes in many files.
More patches will follow that implement CUDA Fortran in the symbol
table and name resolution, and then semantic checking.
Differential Revision: https://reviews.llvm.org/D150159
Fortran doesn't allow inaccessible procedure bindings to be
overridden, and this needs to apply to generic resolution.
When resolving a type-bound generic procedure from another
module, ensure only that the most extended override from its
module is used if it is PRIVATE, not a later apparent override
from another module.
Differential Revision: https://reviews.llvm.org/D150721
Establish a set of optional usage warnings, and enable some
only in "-pedantic" mode that, in our subjective experience
with application codes, seem to issue frequently without
indicating usage that really needs to be corrected. By default,
with this patch the compiler should appear to be somewhat less
persnickety but not less informative.
Differential Revision: https://reviews.llvm.org/D150710
The right-hand sides of assignment statements are always expressions,
never variables. When an assignment statement is converted into a call
to a defined assignment subroutine, and the actual argument being associated
with the second dummy argument is a variable, and the dummy argument does
not have the VALUE attribute, wrap it with parentheses so that lowering
will pass it by means of a temporary.
Fixes https://github.com/llvm/llvm-project/issues/62599.
Differential Revision: https://reviews.llvm.org/D150331
This fixes LEN inquiry on array constructors where the length
expression includes references to the ac-do-variable.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D150149
Make __builtin_c_loc() into an intrinsic function and verify the
special semantic requirements on its actual arguments.
Differential Revision: https://reviews.llvm.org/D149988
Pointer components without default initialization pose some
difficult (or impossible) problems when they appear as right-hand
side targets in pointer assignment statements; they may contain
garbage or stale data that looks enough like a valid descriptor
to cause a crash. Solve the problem by avoiding it -- ensure
that pointers' descriptors are at least minimally established.
Differential Revision: https://reviews.llvm.org/D149979
Recent Flang PowerPC intrinsics patch used resolution variable without checking if it exists first, causing segmentation faults in some scenarios. This patch checks that the resolution variable exists first before usage.
Reviewed By: DanielCChen
Differential Revision: https://reviews.llvm.org/D147616
Implements the PowerPC mtfsf and mtfsfi intrinsics as well as introduces semantic error checking code for PowerPC intrinsics
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D144876
Consolidate aspects of pointer assignment & structure constructor pointer component
checking from Semantics/assignment.cpp and /expression.cpp into /pointer-assignment.cpp,
and add a warning about data targets that are not definable objects
but not hard errors. Specifically, a structure component pointer component data
target is not allowed to be a USE-associated object in a pure context by a numbered
constraint, but the right-hand side data target of a pointer assignment statement
has no such constraint, and that's the new warning.
Differential Revision: https://reviews.llvm.org/D146581
Kind parameters on literals (1_4, 1.0_8, 4_"Unicode") are not
being caught as errors if they're extremely large integer values
that become valid when truncated to C++'s int type.
Differential Revision: https://reviews.llvm.org/D145747
When a global procedure has no explicit interface, emit warnings
when its references are inconsistent implicit procedure interfaces.
Differential Revision: https://reviews.llvm.org/D145097
When a derived type has a PRIVATE type-bound generic binding for
a defined ASSIGNMENT(=), don't use it in scopes outside of the
module that defines the type. We already get this case right
for other type-bound generics, including defined operators,
and for non-type-bound generic interfaces, but the check was
not applied for this case.
Differential Revision: https://reviews.llvm.org/D143826
A scalar value in a structure constructor may correspond to an
array component in the derived type only when that component has
a shape to which the scalar value may be expanded.
Differential Revision: https://reviews.llvm.org/D143822
The recent code that uses an iterative rather than recursive walk
over the parse tree when processing expressions needs to allow for
the rare case in which an intrinsic operator (e.g., +) is extended
by a generic interface in the program.
Differential Revision: https://reviews.llvm.org/D143818
f18 was diagnosing the misuse of a procedure pointer as an output item,
but not the more general case of a procedure designator other than
a pointer.
Differential Revision: https://reviews.llvm.org/D143780
In some circumstances, such as in compile-time array shape analysis,
clients of the utility function ResolveAssociations() don't really
want it to drill all of the way down to an assumed-rank dummy argument.
Add a variation, ResolveAssociationsExceptSelectRank(), that
will return a specific rank case's AssocEntity symbol instead.
This fixes a crash in subscript validation checking that stemmed from
deducing an incorrect number of lower and upper bound expressions
from a specific rank case association entity.
Differential Revision: https://reviews.llvm.org/D143778
In the parse tree visitation framework (Parser/parse-tree-visitor.h)
and in the semantic analyzer for expressions (Semantics/expression.cpp)
avoid crashing due to stack size limitations by using an iterative
traversal algorithm rather than straightforward recursive tree walking.
The iterative approach is the obvious one of building a work queue and
using it to (in the case of the parse tree visitor) call the visitor
object's Pre() and Post() routines on subexpressions in the same order
as they would have been called during a recursive traversal.
This change helps the compiler survive some artificial stress tests
and perhaps with future exposure to machine-generated source code.
Differential Revision: https://reviews.llvm.org/D142771
When a triplet's lower and upper bounds are the same, we can
check them without requiring a constant stride.
Differential Revision: https://reviews.llvm.org/D142943
Array references like A(1) are commonly misparsed as function references,
since the parser has almost no semantic context, and the parse tree is
fixed up later by semantics once it can be disambiguated. In a case
like A(I=1), however, the presence of an argument keyword must prevent
conversion into an array reference. (It might still also be a structure
constructor.)
Differential Revision: https://reviews.llvm.org/D142765
Semantics can catch out-of-range subscript values already when they
appear in DATA statement objects and constant folding of name constant
array indexing; this patch fills the gap by checking known constant
subscript values in other contexts.
Differential Revision: https://reviews.llvm.org/D142764
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
