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
Code in Evaluate/type.cpp was maintaining a very old assumption that
procedure pointers would need to be represented as descriptors. This
is not the case -- they are code or thunk addresses.
Differential Revision: https://reviews.llvm.org/D149984
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
Prior to this change, if you define a module as such with a declare target in it:
module test_0
implicit none
!$omp declare target(no_implicit_materialization_1)
end module test_0
The compiler will crash rather than give some form of reasonable
diagnostic. This patch attempts to fix that.
Reviewers: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D149913
Initial support for USE_DEVICE_PTR clause on OMP TARGET DATA directive.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148254
Allow two currently erroneous cases of !DIR$ IGNORE_TKR errors: allocatable
and pointers, and IGNORE_TKR(R) on (other) arguments passed via descriptors.
Downgrade these cases to warnings when they appear in external interfaces,
since their implementations may well be in C. But retain the error status
on these cases for module procedures, since the Fortran implementation
probably can't work.
Differential Revision: https://reviews.llvm.org/D148833
Implement semantics for the IGNORE_TKR directive as it is interpreted
by the PGI / NVFORTRAN compiler.
Differential Revision: https://reviews.llvm.org/D148643
A fairly recent introduction of runtime I/O APIs called OutputDerivedType()
and InputDerivedType() didn't cover NAMELIST I/O's need to access
non-type-bound generic interfaces for user-defined derived type I/O
when those generic interfaces are defined in some scope other than the
one that defines the derived type.
The patch adds a new data structure shared between lowering
and the runtime that can represent all of the cases that can
arise with non-type-bound defined I/O. It can represent
scopes in which non-type-bound defined I/O generic interfaces
are inaccessible, too, due to IMPORT statements.
The data structure is now an operand to OutputDerivedType() and
InputDerivedType() as well as a data member in the NamelistGroup
structure.
Differential Revision: https://reviews.llvm.org/D148257
The extents, if any, of the HARVEST= actual argument must be known
at execution time for the call to be implemented.
Differential Revision: https://reviews.llvm.org/D147391
The intrinsic function table entry for NORM2 treats its DIM=
argument as if it can be dynamically optional; this is wrong,
and it should be treated in the same way as DIM= is for other
transformational intrinsic functions like SUM.
Differential Revision: https://reviews.llvm.org/D147390
When the same name is pulled into a scope more than once via
USE and IMPORT, emit an error if its resolutions are ambiguous,
or (as an extension like some other compilers) emit a portability
warning when the names all resolve to the same symbol.
Differential Revision: https://reviews.llvm.org/D147388
Many semantic checks for constraints related to PURE subprograms
can be implemented in terms of Semantics' "definable.h" utilities,
slightly expanded. Replace some particular PURE constraint
checks with calls to WhyNotDefinable(), except for cases that
had better specific error messages, and start checking some
missing constraints with DEALLOCATE statements and local
variable declarations.
Differential Revision: https://reviews.llvm.org/D147389
Call GetUltimate() before checking a user-defined derived type I/O specific
procedure so that the checks work on a USE-associated procedure. And
require their character arguments to have the default CHARACTER kind.
Differential Revision: https://reviews.llvm.org/D147386
Error only applies if it is a whole array. Page 157 in OpenMP 5.2
standard.
Reviewed By: TIFitis
Differential Revision: https://reviews.llvm.org/D147142
A CONTIGUOUS entity must be an array pointer, assumed-shape dummy array,
or assumed-rank dummy argument (C752, C830). As currently implemented,
f18 only implements the array requirement if the entity is a pointer.
Combine these checks and start issuing citations to scalars.
Differential Revision: https://reviews.llvm.org/D146588
The compiler accepts arguments of any rank, or assumed rank, to a host
of intrinsic inquiry functions. For scalars, this is correct for most
of them, but the standard (and other compilers) prohibit scalar arguments
to SIZE, LBOUND, and UBOUND (without DIM=).
There are meaningful interpretations for these intrinsic inquiries
on scalars, but since there's no portability concern here, continuing
to support them would be an unjustifiable extension.
Differential Revision: https://reviews.llvm.org/D146587
C721 says that a type parameter value of '*' is permitted in the type-spec
for a named constant; C795 says that such type parameters are allowed
in type-specs only for a few kinds of things, not including named
constants. The interpretation seems to depend on context, with C721
applying to intrinsic types (i.e., character) and C795 applying only
to derived types.
Differential Revision: https://reviews.llvm.org/D146586
The semantic checking of DO CONCURRENT bodies looks only at the
parse tree, not the typed expressions produced from it, so it
misses calls to defined assignment subroutines that arise from
assignment statements that resolve via generic interfaces into
subroutine calls. Extend the checking to peek into the typed
assignment operations left on the parse tree by semantics.
Differential Revision: https://reviews.llvm.org/D146585
The utility routine in semantics that determines whether an
executable construct constitutes an image control statement
was not examining the single action statement controlled by
a non-construct IF statement, e.g. 'IF(P) STOP'.
Differential Revision: https://reviews.llvm.org/D146584
Presently, semantics doesn't check for discrepancies between known
constant corresponding LEN type parameters between the declared type
of an allocatable/pointer and either the type-spec or the SOURCE=/MOLD=
on an ALLOCATE statement.
This allows discrepancies between character lengths to go unchecked.
Some compilers accept mismatched character lengths on SOURCE=/MOLD=
and the allocate object, and that's useful and unambiguous feature
that already works in f18 via truncation or padding. A portability
warning should issue, however.
But for mismatched character lengths between an allocate object and
an explicit type-spec, and for any mismatch between derived type
LEN type parameters, an error is appropriate.
Differential Revision: https://reviews.llvm.org/D146583
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
The data statement variable checker is missing some cases, like expressions
that are not variables. Run the checker first to enjoy its very specific
error messages, but when it finds no problems, still apply a general
check that an expression is a "variable" and also not a constant expression
at the top level as a backstop.
Differential Revision: https://reviews.llvm.org/D146580
Constraint checking for explicit SAVE attributes is more
accurate when done along with other declaration checking, rather
than on the fly during name resolution. This allows us to
catch attempts to attach explicit SAVE attributes to anything
that can't have one (constraints C859, C860).
Also delete `IsSave()`, whose few remaining uses were changed to the
more general `IsSaved()` predicate that seems more correct for
those uses, returning true for both explicit and implied SAVE
attributes.
Differential Revision: https://reviews.llvm.org/D146579
A PRIVATE procedure binding in a derived type extension may not
be an override of a PUBLIC procedure binding. Declaration checking
for this case was working only in the presence of an explicit
PUBLIC accessibility attribute, when it should be checking for the
absence of a PRIVATE accessibility attribute.
Differential Revision: https://reviews.llvm.org/D146577
Constraint C1406 in Fortran 2018 prohibits the USE of the same module
name as both an intrinsic module and a non-intrinsic module in a scope.
The current check misinterprets the constraint as applying only to
explicitly INTRINSIC or NON_INTRINSIC module natures.
Change the check to also apply to non-explicit module natures, and
also downgrade it to a portability warning, since there is no ambiguity
and I suspect that we need to accept this usage when building f18's
own intrinsic modules.
Differential Revision: https://reviews.llvm.org/D146576
A positional (non-keyword) actual argument or alternate return label is not
allowed to follow an actual argument with a keyword.
Differential Revision: https://reviews.llvm.org/D146575
When multiple scopes in a compilation define interfaces (explicit
or implicit) for an external procedure, warn when those interfaces
are inconsistent.
Differential Revision: https://reviews.llvm.org/D146574
Procedures with the EXTERNAL attribute (explicit or implied) are
not permitted to be ALLOCATABLE or be arrays if their interfaces
are implicit.
Differential Revision: https://reviews.llvm.org/D146572
The present I/O infrastructure for user-defined derived type I/O
subroutines works fine for type-bound I/O generic bindings. It also works
for explicit INTERFACE blocks and GENERIC statements that define
UDDIO subroutines in the same scope as the definition of the derived type,
so long as the specific procedures in those bindings are module procedures
or external procedures.
For non-type-bound UDDTIO specific procedures that are dummy procedures,
thunks of inner procedures, or procedure pointers, or that are defined with
interfaces or GENERIC outside the scope of the definition of the derived
type, a new runtime I/O API is needed so that lowering can generate
a call that supplies the appropriate procedure as well as the defined
type instance.
This patch specifies and implements this new runtime API and provides
utility routines for lowering to use to determine whether it should be
called for any particular OutputItem or InputItem in the parse tree.
Differential Revision: https://reviews.llvm.org/D146571
Added semantics tests for aspects of CHANGE TEAM statements which are not duplicates from FORM TEAM statements.
Reviewed By: ktras
Differential Revision: https://reviews.llvm.org/D137908
Some Fortran compilers allow kinds of LOGICAL other than C_BOOL
for the types of dummy arguments to interoperable (BIND(C))
procedures. As any kind of LOGICAL can be converted to any
other without loss of information, this seems to be a useful
unambiguous extension that is attested in real codes; accept it
for scalars with a portability warning.
Differential Revision: https://reviews.llvm.org/D145968
As the new test here shows by failing with the current compiler with
a bogus error message about indistinguishable specific procedures in
a generic interface, name resolution needs to take care to not
copy a USE-associated generic into the current scope for extension
when the USE association is actually into an enclosing scope.
Differential Revision: https://reviews.llvm.org/D145750
Non-DEFERRED procedure binding checking can't blindly accept
all procedures defined in modules -- they can't be ABSTRACT
interfaces. And GetUltimate() must be used rather than
FindSubprogram(); the latter will resolve to a procedure's
interface in the case of "procedure(interface) :: external",
not "external".
Differential Revision: https://reviews.llvm.org/D145749
The compiler presently detects different dummy object array ranks;
extend the compatibility check to also note discrepancies in corresponding
constant dummy argument extents.
Differential Revision: https://reviews.llvm.org/D145748
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
Declaration checking in semantics was only examining symbols with
explicit BIND(C) attributes; extend it to also check dummy arguments
to such procedures.
Differential Revision: https://reviews.llvm.org/D145746
As a near-universal extension, Fortran compilers permit forward references
to dummy arguments and variables in COMMON blocks from specification expressions
before an explicit type-declaration-stmt appears for those variables
under IMPLICIT NONE, so long as those variables are later explicitly typed
with the types that regular implicit typing rules would have given them
(usually default INTEGER).
F18 implemented this extension for dummy arguments, but not variables in
COMMON blocks. Extend the extension to also accept variables in COMMON.
Differential Revision: https://reviews.llvm.org/D145743
A SELECT TYPE statement's selector must be a variable or expression,
not a procedure; specifically, a function with a polymorphic result
is unacceptable.
Differential Revision: https://reviews.llvm.org/D145742
When a parameterized derived type has FINAL subroutines, only
those FINAL subroutines whose dummy argument's type matches the
type parameter values of a particular instantiation are relevant
to that instantiation.
Differential Revision: https://reviews.llvm.org/D145741
The outer context private check for reduction variables was firing
for all constructs. This check is not applicable to non-worksharing
constructs.
OpenMP 5.2: Section 5.5.8
A list item that appears in a reduction clause on a worksharing construct
must be shared in the parallel region to which a correspodning worksharing
region binds.
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D144824
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
A BLOCK construct may not contain a statement function definition;
but it may of course contain an assignment statement with an array
element on its left-hand side that looks like a statement function
definition. These misparsed statement functions are converted
into assignment statements during semantics once it is clear what
they are. Move the C1107 check for a statement function definition
in a block construct into declaration checking, which is where it
probably should have been in the first place anyway.
Differential Revision: https://reviews.llvm.org/D145112
The compiler currently ignores attributes for PASS dummy arguments that
are incompatible between a type-bound procedure in an extended type and
the binding of the same name that it overrides in an ancestor type,
if any. Strengthen this checking so that discrepancies between attributes
and intents are caught, and add some tests.
Differential Revision: https://reviews.llvm.org/D145110
A generic procedure binding in an extended derived type may not have the
same name as a symbol inherited from an ancestor type unless that inherited
symbol is also a generic TBP. Since generic names can be things like
"ASSIGNMENT(=)", name resolution doesn't use OkToAddComponent() for
generic TBPs, which would have caught this error as it does for other
symbols in derived types, so it must be special-cased.
Differential Revision: https://reviews.llvm.org/D145109
The Fortran standard's various restrictions on the use of BIND(C)
often depend more on the presence or absence of an explicit NAME=
specification rather than on its value, but semantics and module
file generation aren't making distinctions between explicit NAME=
specifications that happen to match the default name and declarations
that don't have NAME=. Tweak semantics and module file generation
to conform, and also complain when named BIND(C) attributes are
erroneously applied to entities that can't support them, like
ABSTRACT interfaces.
Differential Revision: https://reviews.llvm.org/D145107
Fortran doesn't allow a BIND(C) variable or a component of a BIND(C)
type to be an array with no elements.
Differential Revision: https://reviews.llvm.org/D145106
When a procedure binding in a derived type has PRIVATE accessibility,
it may not be an override of a type-bound procedure that is accessible.
Differential Revision: https://reviews.llvm.org/D145104
Generic interfaces are not permitted to have intrinsic procedures or
statement functions as specific procedures.
Differential Revision: https://reviews.llvm.org/D145103
A procedure defined in an ABSTRACT INTERFACE may not appear as
a specific procedure in a generic interface.
Differential Revision: https://reviews.llvm.org/D145102
