Make tests expect the (correctly) emitted warnings using the WARNING
directive. This directive is non-functional now, but will be recognised
by test_errors.py when D125804 is landed. This patch is a preparation
for D125804.
For most tests, we add missing WARNING directives for emitted warnings,
but there are exceptions:
- for int-literals.f90 and resolve31.f90 we pass -pedantic to the
frontend driver, so that the expected warnings are actually emitted.
- for block-data01.f90 and resolve42.f90 we change the tests so that
warnings, which appear unintentional, are not emitted. While testing
the warning in question (padding added for alignment in common block)
would be desired, that is beyond the scope of this patch. This
warning is target-dependent.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D131987
This patch lowers correctly operands with array section
and derived-type component.
Depends on D131764
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D131765
This patch adds lowering support for default clause.
1. During symbol resolution in semantics, should the enclosing context
have a default data sharing clause defined and a `parser::Name` is not
attached to an explicit data sharing clause, the
`semantics::Symbol::Flag::OmpPrivate` flag (in case of
default(private)) and `semantics::Symbol::Flag::OmpFirstprivate` flag
(in case of default(firstprivate)) is added to the symbol.
2. During lowering, all symbols having either
`semantics::Symbol::Flag::OmpPrivate` or
`semantics::Symbol::Flag::OmpFirstprivate` flag are collected and
privatised appropriately.
Co-authored-by: Peixin Qiao <qiaopeixin@huawei.com>
Reviewed by: peixin
Differential Revision: https://reviews.llvm.org/D123930
Procedure bindings with explicit interfaces don't work when the
interface is shadowed by a generic interface of the same name,
and can produce spurious semantic error messages. Extend the
characterization and checking code for such things, and the utility
functionns on which they depend, to dig through generics when they
occlude interface-defining subprograms. This is done on demand in
checking code, not once during name resolution, because the
procedures in question may also be forward-referenced.
Differential Revision: https://reviews.llvm.org/D131105
diff --git a/flang/include/flang/Semantics/symbol.h b/flang/include/flang/Semantics/symbol.h
index e79f8ab6503e..0b03bf06eb73 100644
--- a/flang/include/flang/Semantics/symbol.h
Allow internal I/O to support non-default kinds of CHARACTER.
The I/O runtime design anticipated this standard feature, but
this patch is somewhat larger than I thought it would be because
many code sites had to have assumptions about units (characters
vs. bytes) brought into harmony, and some encoding utilities
had to be pulled out of IoStatementState and templatized into
their own new header file so that they are available to formatted
output code without having to "thread" an IoStatementState reference
through many call chains.
Differential Revision: https://reviews.llvm.org/D131107
Defined generic procedure interfaces are allowed to shadow non-generic
procedures of the same name in the same scope (whether or not
that non-generic procedure is a specific procedure of the generic).
When making a copy of a generic interface symbol so that it can
be locally modified or be merged with another generic, don't forget
about the homonymous non-generic procedure that it might shadow.
Differential Revision: https://reviews.llvm.org/D131103
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
Add stopped_images to the list of intrinsic functions. Add a
semantics test for stopped_images.
Reviewed By: klausler, ngeorge1098
Differential Revision: https://reviews.llvm.org/D129513
This supports checks in C1801-C1805 for derived type with BIND attribute.
The other compilers such as 'gfortran' and 'ifort' do not report error
for C1802 and C1805, so emit warnings for them.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D130438
This patch adds lowering support for default clause.
1. During symbol resolution in semantics, should the enclosing context have
a default data sharing clause defined and a `parser::Name` is not attached
to an explicit data sharing clause, the
`semantics::Symbol::Flag::OmpPrivate` flag (in case of `default(private)`)
and `semantics::Symbol::Flag::OmpFirstprivate` flag (in case of
`default(firstprivate)`) is added to the symbol.
2. During lowering, all symbols having either
`semantics::Symbol::Flag::OmpPrivate` or
`semantics::Symbol::Flag::OmpFirstprivate` flag are collected and
privatised appropriately.
Co-authored-by: Peixin Qiao <qiaopeixin@huawei.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D123930
The predicate "CanBeCalledViaImplicitInterface()" was returning false for
restricted specific intrinsic functions (e.g., SIN) because their procedure
characteristics have the elemental attribute; this leads to a bogus semantic
error when one attempts to use them as proc-targets in procedure pointer
assignment statements when the left-hand side of the assignment is a procedure
pointer with an implicit interface. However, these restricted specific intrinsic
functions have always been allowed as special cases for such usage -- it is
as if they are elemental when it is necessary for them to be so, but not
when it's a problem.
Differential Revision: https://reviews.llvm.org/D130386
When a procedure pointer is associated with a procedure target, f18
will emit hard error messages if the pointer is incompatible with the
target in a way that would cause the program to not work if the
procedure pointer were actually called. However, in the context of
the ASSOCIATED() intrinsic, the compiler should not consider a query
to be a compilation-time error if the pointer and the target are
incompatible. The standard gives us sufficient wiggle room here
to treat these cases as warnings.
Attempts to use ASSOCIATED to test whether a procedure pointer is
associated with a data object, or vice versa, remain errors.
Differential Revision: https://reviews.llvm.org/D130384
f18 intentionally does not support the spottily-implemented language extension
in which one can pass NULL() for an allocatable dummy argument. This is perhaps
a sanctioned side effect in other compilers of the fact that they pass distinct
"base address" and "descriptor address" physical arguments.
Make the error message in this case more specific to the circumstances, and
add a note to Extensions.md to clarify that this behavior is intended.
(We could, with some effort in lowering, support passing NULL for an INTENT(IN)
allocatable dummy, but let's see whether such nonconforming usage appears
in a real application before spending any more time on it.)
Differential Revision: https://reviews.llvm.org/D130380
The predicate IsHostAssocited() was implemented in a way that would
return true only for cases of host association into a module or inner
subprogram. Technically, the use of a name in a BLOCK construct
that is not declared therein is considered in the Fortran standard
to also be a form of host association, and this matters when doing
error checking on DATA statements.
Differential Revision: https://reviews.llvm.org/D130388
When a procedure pointer with no interface is associated with
an EXTERNAL name with no interface information, but it is later
inferred that the procedure pointer must be a subroutine because it
appears in a CALL statement, don't complain that the EXTERNAL name
is not also known to be a subroutine.
Subroutine vs. function errors are still caught in procedure pointer
assignment compatibility checking; this fix simply ensures that those
more nuanced tests are not overridded by the attribute set equality test.
Also, leave in some code for dumping the differing attributes in legitimate
error cases that was added in the coures of debugging the specific problem.
Differential Revision: https://reviews.llvm.org/D130385
Fortran specifically allows character-valued I/O specifiers
to have trailing blanks, e.g. OPEN(666,STATUS='SCRATCH ').
The runtime I/O library already handles them, but the I/O
static checks in semantics do not.
Differential Revision: https://reviews.llvm.org/D130381
Add the collective subroutine, co_sum, to the list of intrinsics.
In accordance with 16.9.50 and 16.9.137, add a check for and an
error if coindexed objects are being passed to certain arguments
in co_sum and in move_alloc. Add a semantics test to check that
this error is successfully caught in calls to move_alloc. Remove
the XFAIL directive, update the ERROR directives and add both
standard-conforming and non-standard conforming calls to the
semantics test for co_sum.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D114134
This patch improves semantic checks for hint clause.
It checks "hint-expression is a constant expression
that evaluates to a scalar value with kind
`omp_sync_hint_kind` and a value that is a valid
synchronization hint."
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D127615
Fortran permits forward references to derived types in contexts that don't
require knowledge of the derived type definition for semantic analysis,
such as in the declaration of a pointer or allocatable variable or component.
But when the forward-referenced derived type is used later for a component
reference, it is possible for the DerivedTypeSpec in he base variable or component
declaration to still have a null scope pointer even if the type has been defined,
since DerivedTypeSpec and TypeSpec objects are created in scopes of use
rather than in scopes of definition. The fix is to call
DerivedTypeSpec::Instantiate() in the name resolution of each component
name so that the scope gets filled in if it is still null.
Differential Revision: https://reviews.llvm.org/D129681
Most modern Fortran programs declare procedure pointers with a
procedure-declaration-stmt, but it's also possible to declare one
with a type-declaration-stmt with a POINTER attribute. In this
case, e.g. "real, external, pointer :: p => null()" the initializer
is required to be a null-init. The parse tree traversal in name
resolution would visit the null-init if the symbol were an object
pointer only, leading to a crash in the case of a procedure pointer.
That explanation of the bug is longer than the fix. In short,
ensure that a null-init in an entity-decl is visited for both
species of pointers.
Differential Revision: https://reviews.llvm.org/D129676
Some procedure pointers and EXTERNAL procedures have neither
explicit interfaces nor result types; these procedures are obviously
not known to be functions, but they could be, so semantics must not
assume that they are necessarily subroutines. Refine the procedure
pointer / dummy procedure compatibility check to handle these more
ambiguous cases and not elicit inappropriate error messages.
Differential Revision: https://reviews.llvm.org/D129674
Add a semantics test for the intrinsic function image_status. Add
a check and restriction on the image argument in image_status,
ensuring that it is a positive value. Add same check on the
size argument of the intrinsic ishftc. Add another check on
the shift argument of ishftc, ensuring that it is less than or
equal to the size argument. Add a short semantics test checking
these restrictions in ishftc function calls.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D128009
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.
Add non-standard conforming calls that violate the intent(inout)
of errmsg argument for co_sum, co_max, co_min, and co_broadcast.
Add non-standard conforming calls that violate the argument
typing of errmsg argument for co_max, co_min, and co_broadcast.
Add standard conforming calls that reorder keyword arguments
for co_sum and co_reduce.
Reviewed By: ktras
Differential Revision: https://reviews.llvm.org/D128468
Add new semantics test for team_number and rename existing
team_number semantics test.
Reviewed By: ktras
Differential Revision: https://reviews.llvm.org/D128309
As Fortran 2018 8.6.4(1), the BIND statement specifies the BIND attribute
for a list of variables and common blocks.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D127120
If BIND(C) appears on an internal procedure, it must have a null binding
label, i.e. BIND(C,NAME="").
Also address conflicts with D127725 which was merged during development.
Differential Revision: https://reviews.llvm.org/D128676
While it is indeed an error to use SIZE, SHAPE, or UBOUND on an
assumed-shape dummy argument without also supplying a DIM= argument
to the intrinsic function, it is *not* an error to use these intrinsic
functions on sections or expressions of such arrays. Refine the test
used for the error message.
Differential Revision: https://reviews.llvm.org/D128391
As Fortran 2018 C1520, if proc-language-binding-spec with NAME= is
specified, then proc-decl-list shall contain exactly one proc-decl,
which shall neither have the POINTER attribute nor be a dummy procedure.
Add this check.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D127725
This adds the test case with portability warning preparing for D125804,
which supports checking for portability warnings in test_errors.py.
Reviewed By: ekieri
Differential Revision: https://reviews.llvm.org/D127821
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
For BIND(C) statement, two common block with the same name can have the
same bind name. Fix the regression failure by adding this check. Also add
the regression tests.
Co-authored-by: Jean Perier <jperier@nvidia.com>
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D127841
As OpenMP 5.0, for firstprivate, lastprivate, copyin, and copyprivate
clauses, if the list item is a polymorphic variable with the allocatable
attribute, the behavior is unspecified.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D127601
Add failed_images to the list of intrinsic functions. Add a
semantics test for failed_images.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D126805
num_images had previously been added to the list of intrinsics
before the type team_type had been implemented. Now that team_type
is implemented, add the num_images call that has the team argument.
Update the semantics tests for num_images.
Reviewed By: craig.rasmussen
Differential Revision: https://reviews.llvm.org/D126734
As Fortran 2018 C802 and C873, if bind name is specified, there can only
be only one entity. The check for common block is missed before. As
Fortran 2018 8.5.5 point 2, the bind name is one identifier, which is
unique. That is, one entity can not have multiple bind names. Also add
this check.
Reviewed By: klausler, Jean Perier
Differential Revision: https://reviews.llvm.org/D126961
