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
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
After rewriting:
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
This reverts commit 5faf45a3d24e603cbc8fe4eb45da386653dae5e5.
Once again arcanist stripped the co-author metadata. I'm going to add it to the revision description and try one last time.
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
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
TYPE(*) arguments fell through in IS_CONTIGUOUS folding
because they are not Expr<SomeType>. Expose entry point for
symbols in IsContiguous and use that.
The added test revealed that IS_CONTIGUOUS was folded to
false for assumed rank arguments. Fix this: the contiguity of
assumed rank without the CONTIGUOUS argument can only be
verified at runtime.
Differential Revision: https://reviews.llvm.org/D148128
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
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
/data/llvm-project/flang/lib/Semantics/check-call.cpp🔢29: error: comparison of integers of different signs: 'int' and 'size_type' (aka 'unsigned long') [-Werror,-Wsign-compare]
CHECK(index >= 0 && index < actuals.size());
~~~~~ ^ ~~~~~~~~~~~~~~
/data/llvm-project/flang/include/flang/Common/idioms.h:89:20: note: expanded from macro 'CHECK'
^
1 error generated.
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
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
Don't check ranks when a pointer actual argument is associated with
a pointer assumed-rank dummy argument.
Differential Revision: https://reviews.llvm.org/D147052
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
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
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
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
