In a pure context, a pointer acquired from an INTENT(IN) dummy argument
may not be copied. Catch the case in which the pointer is a component
of an allocatable component at some depth of nesting.
(This patch adds a new component iterator kind that is a variant of
a potential subobject component iterator; it visits all potential
subobject components, plus pointers, into which it does not descend.)
Differential Revision: https://reviews.llvm.org/D139161
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
Given a MODULE SUBROUTINE or MODULE FUNCTION interface followed
later by a corresponding separate module subprogram definition in a
MODULE PROCEDURE, the copies of the interface's dummy argument and
function result symbols that populate the initial scope of that
MODULE PROCEDURE need to have any symbol references in their types
or bounds adjusted to point to their new counterparts.
Differential Revision: https://reviews.llvm.org/D139200
Fix#59177, add check for dimensionality for shape argument against rank of FPTR argument in c_f_pointer
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D138743
Enforce detectable compilation-time violations of restrictions on the
arguments to the TRANSFER() intrinsic function (16.9.163) with
error messages, and mark other potential problems with warnings.
Differential Revision: https://reviews.llvm.org/D139157
The semantics of many transformational intrinsic functions, especially
reductions like SUM(), are determined by the static presence or absence
of a DIM= argument. In the case of an actual DIM= argument that is
syntactically present but could be dynamically absent at execution time
(due to being OPTIONAL, POINTER, or ALLOCATABLE), f18 should emit some
kind of diagnostic message.
Other compilers either ignore this possibility or treat it as a hard
error; neither really seems correct, so let's do something more nuanced.
For cases where the dynamic absence of a value for DIM doesn't pose
as much of a risk because it lowering is going to assume that it's
equal to 1 anyway, emit only a portability warning.
For other cases where the generated code or runtime support library
will need the value of DIM= during execution, emit a warning that
the use of an OPTIONAL/POINTER/ALLOCATABLE variable or component
here is dicey and should be reconsidered.
While here, also catch bad constant DIM= values.
Differential Revision: https://reviews.llvm.org/D139155
An assumed-size dummy array argument with INTENT(OUT) can't have a type
that might require any runtime (re)initialization, since the size of the
array is not known.
Differential Revision: https://reviews.llvm.org/D139149
Modules, submodules, main programs, and BLOCK DATA subprograms have names
that cannot be used within their scope, so we allow those names to be
used for other entities in the scope. This might not be entirely
conformant with the language standard, so warn about it.
Differential Revision: https://reviews.llvm.org/D139146
The TARGET= argument of the ASSOCIATED() intrinsic function must be a valid
pointer assignment statement target. Ensure that it does not contain a vector
subscript or any coindexing, either of which would imply a data copy into
temporary storage.
Differential Revision: https://reviews.llvm.org/D139145
19.6.8 forbids using an INTENT(IN) pointer dummy argument in a pointer association
context, and associated such a pointer with a dummy argument of INTENT(IN OUT) or
INTENT(OUT) is a circumstance that needs to be caught as an error.
Differential Revision: https://reviews.llvm.org/D139138
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
When a character-valued function is passed as an actual argument, and both
the actual function and the dummy argument have explicit result lengths, take them
into account when testing for compatibility.
Differential Revision: https://reviews.llvm.org/D139129
Standard Fortran allows type-bound procedure bindings to only
be called, and disallows them from being used in other contexts
where a procedure name can be: as the target of a procedure pointer
assignment statement, and as an actual argument that corresponds
to a dummy procedure. So long as the interfaces match, there's
no good reason for these uses to be errors, and there some obvious
use cases in polymorphic programming. So emit portability warnings
rather than errors, and document this usage as an extension.
Differential Revision: https://reviews.llvm.org/D139127
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
12.6.3p5 requires an I/O data list item to have a defined I/O procedure
if it is polymorphic. (We could defer this checking to the runtime,
but no other Fortran compiler does so, and we would also have to be
able to catch the case of an allocatable or pointer direct component
in the absence of a defined I/O subroutine.)
Also includes a patch to name resolution that ensures that a
SELECT TYPE construct entity is polymorphic in the domain of a
CLASS IS guard.
Also ensures that non-defined I/O of types with PRIVATE components
is caught.
Differential Revision: https://reviews.llvm.org/D139050
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
Definability checking is unconditionally flagging the use of a polymorphic
variable as an actual argument for a procedure reference in a PURE subprogram
unless the corresponding dummy is INTENT(IN). This isn't necessary, since
an INTENT(OUT) polymorphic dummy is already caught as an error in the definition
of the callee, which must also be PURE; and an INTENT(IN OUT) or intent-free
dummy is allowed to be passed a polymorphic actual in a PURE context, with
any attempt to deallocate it being caught in the callee.
So add a flag to the definability checker to disable the "polymorphic
definition in PURE context" check when using it to check actual arguments.
Differential Revision: https://reviews.llvm.org/D139044
A recent change moved some checking code from name resolution into
declaration checking, and inadvertently disabled C702 checking for
procedure entities. Fix.
Differential Revision: https://reviews.llvm.org/D139043
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 functionality of LSHIFT and RSHIFT intrinsics is the same as the
standard SHIFTL and SHIFTA intrinsics respectively. The patch is to
alias the two intrinsics to the standardized ones.
Differential Revision: https://reviews.llvm.org/D138839
OpenMP 5.0 adds support for the "requires" directive. This patch adds parser support for it in flang.
Differential revision: https://reviews.llvm.org/D136867
Add the atomic subroutine, atomic_xor, to the list of
intrinsic subroutines, add its last dummy argument to a check
for a coindexed-object, and update test.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137196
Add the atomic subroutine, atomic_or, to the list of
intrinsic subroutines, add its last dummy argument to a check
for a coindexed-object, and update test.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137097
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
Many intrinsic functions in Fortran require that two or more of their
arguments have types that agree in the values of all of their type
parameters, while others only require the same type category and kind
type parameters but not lengths, including the important case of
CHARACTER. The intrinsic procedure tables need to be adjusted in
some cases so that discrepancies in character lengths that are known
at compilation time can be diagnosed as errors where they should be,
as in for example MOVE_ALLOC().
Differential Revision: https://reviews.llvm.org/D137032
There are some exceptional cases where the compiler permits association of
procedure pointers or dummy arguments with slightly incompatible procedure
targets, but they should not override any incompatibilty of function
result types.
(Includes a second fix to resolve the original motivating test failure, in
which a COMPLEX intrinsic function was getting its result kind divided by
two due to an implicit C++ conversion of the kind to a "*kind" parse tree
node, and those legacy "COMPLEX*size" type designators' values are twice
the type kind value.)
Differential Revision: https://reviews.llvm.org/D136964
Add the atomic subroutine, atomic_and, to the list of
intrinsic subroutines, add its last dummy argument to a check
for coindexed-object, and update test.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D136907
Some of the circumstances that require that a procedure have an
explicit interface at a point of call due to a characteristic of
a dummy argument apply to dummy procedures, too.
Differential Revision: https://reviews.llvm.org/D136994
A Fortran program may not specify a particular attribute multiple
times for the same entity in a scope.
Differential Revision: https://reviews.llvm.org/D136991
When a dummy argument is a procedure pointer without INTENT(IN),
any actual argument must also be a procedure pointer, whether the
dummy procedure pointer's interface is explicit or not.
Differential Revision: https://reviews.llvm.org/D136989
We implemented 19.3.4p1 literally in name resolution:
A component name has the scope of its derived-type definition. Outside the type definition,
it may also appear within a designator of a component of a structure of that type or as a
component keyword in a structure constructor for that type.
and within the derived-type definition would resolve the "bare"
names of components in specification inquiries and other contexts to
those components, not to any symbols in the enclosing scopes.
It turns out that most Fortran compilers resolve only "bare" names thus
when they are type parameters, and the names of data and procedure components
do not shadow exterior symbols. Adjust name resolution to follow that
precedent rather than what seems to be clear language in the standard.
Differential Revision: https://reviews.llvm.org/D136984
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
Enforce remaining semantic restrictions on the arguments to MOVE_ALLOC,
namely that the first two arguments must be allocatable (!) and that
if the source is polymorphic, so must the destination be.
Differential Revision: https://reviews.llvm.org/D136973
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
Semantics checks C702, which disallows deferred type parameters for
any entity that is neither an allocatable nor a pointer, only during
name resolution of type declaration statements. This check needs to
be broader, since Fortran entities can have their types specified in
other ways. Rewrite the check and move it to the general declaration
checking pass.
Differential Revision: https://reviews.llvm.org/D136970
Fortran's constraint C721 allows an assumed-length CHARACTER
entity to be declared in a very limited set of circumstances that
does not include an explicit external interface definition.
Differential Revision: https://reviews.llvm.org/D136963
When a derived type has a procedure pointer component with no interface,
we can't do a lot of checking on its call sites, but we can at least require
that the same procedure pointer component be used consistently as either
a function or as a subroutine, but not both.
Differential Revision: https://reviews.llvm.org/D136905
Some intrinsic functions can handle NULL() as an actual argument; most
can't. Distinguish the two with a new ArgFlag facility in the intrinsic
procedure table. Also transform some confusing Optionality codes that
were standing in for flags into ArgFlags. Last, return false for a NULL()
pointer from the utility IsActuallyConstant(), ensuring that it can
still deal with a nested NULL() for components in structure constructors.
Differential Revision: https://reviews.llvm.org/D136893
Fortran famously allows a generic interface definition to share a
scope with a procedure or derived type of the same name. When that
shadowed name is accessed via host or USE association, but is also
defined by an interface in the generic, then name resolution needs
to fix up the representation of the shadowing so that the new interface
definition is seen as the shadowed symbol -- the host or USE associated
name is not material to the situation. See the new test case for
particular examples.
Differential Revision: https://reviews.llvm.org/D136891
Add the atomic subroutine, atomic_fetch_xor, to the list of
intrinsic subroutines, add its last dummy argument to a check
for coindexed-object, and update test.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D136804
Add the atomic subroutine, atomic_fetch_and, to the list of
intrinsic subroutines, add its last dummy argument to a check
for coindexed-object, and update test.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136720
Add three tests for lock-stmt. The first includes
standard-conforming statements, the second includes
non-standard-conforming statements because of errors where
something unexpected occurs, such as a missing lock-variable,
and the third includes non-standard-conforming statements
because of semantic errors, such as type or rank mismatches.
Reviewed By: rouson
Differential Revision: https://reviews.llvm.org/D136628
Add the atomic subroutine, atomic_fetch_add, to the list of
intrinsic subroutines, add its last dummy argument to a check
for coindexed-object, and update test.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D136625
