A recent fix beefed up semantics checking to catch the case of a call
to an external assumed-length character function; this check has false
positives in the case of an assumed-length character function that is
a dummy procedure. These do have a length that is passed in extra
compiler-created arguments. This patch refines the check and undoes some
changes to tests.
Differential Revision: https://reviews.llvm.org/D126390
This is a support for " #pragma omp atomic compare fail ". It has Parser & AST support for now.
Reviewed By: tianshilei1992
Differential Revision: https://reviews.llvm.org/D123235
Since the FIR operations are mostly structured, it is only the functions
that could contain multiple blocks inside an operation. This changes
with OpenMP since OpenMP regions can contain multiple blocks. For
unstructured code, the blocks are created in advance and belong to the
top-level function. This caused code in OpenMP region to be placed under
the function level.
In this fix, if the OpenMP region is unstructured then new blocks are
created inside it.
Note1: This is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project. The code in this patch is a
subset of the changes in https://github.com/flang-compiler/f18-llvm-project/pull/1178.
Reviewed By: vdonaldson
Differential Revision: https://reviews.llvm.org/D126293
Co-authored-by: Val Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
The derived type information table construction code had a
crash whose root cause was replacing an expression with one
of its operands -- the deletion of the LHS of that assignment
led to the RHS being invalidated before it could be read.
Fix by cloning the RHS. Also update a TODO message to the
new "_todo_en_US" message class and add a comment about how
it should be resolved.
Differential Revision: https://reviews.llvm.org/D126154
The scalar-default-character-expression that defines the interoperable
name of a function or subroutine (or interface) must have its names
resolved within the context of the subprogram, despite its appearance
on a function-stmt or a subroutine-stmt. Failure to do so can lead
to bogus errors or to incorrect results.
The solution is to defer name resolution for function-stmt suffixes
(but not entry-stmt suffixes) and for subroutine-stmt language binding
specifications to EndSubprogram(). (Their resolution only need to be
deferred to the end of the specification part, but it's cleanest to
deal with it in EndSubprogram().)
Differential Revision: https://reviews.llvm.org/D126153
User-defined derived type I/O subroutines need to be unique for
a given type and operation in any scope, but it is acceptable
to have more than one defined I/O subroutine so long as only one
of them is visible.
Differential Revision: https://reviews.llvm.org/D126152
A utility predicate in semantics was incorrectly determining that
an INTERFACE ASSIGNMENT(=) (or other form of generic) could not have
a specific procedure with an unlimited polymorphic second argument.
This led to a crash later in expression analysis. Fix, and
extend tests.
Differential Revision: https://reviews.llvm.org/D126151
The purity or impurity of a call to a generic interface
depends on the attributes of the specific procedure or specific
binding. Change expression analysis of calls to generic interfaces
to replace the symbol in the parse tree with the specific procedure
or binding; this ensures that later checking for purity in
DO CONCURRENT and other contexts will be accurate.
Remove an "XFAIL" from a test that now passes again with this fix.
Differential Revision: https://reviews.llvm.org/D126150
Name resolution for subprograms checks whether the name is already
present in the enclosing scope as a generic interface, so that the
case of a generic with the same name as one of its specifics can be
handled. The particular means by which the enclosing scope is searched
for the name would resolve the name (bind a symbol to it) as a side
effect. This turns out to be the wrong thing to do when the subprogram
is going to have its symbol created in another scope to cope with its
BIND(C,NAME="name") name, and its Fortran name is already present in the
enclosing scope for a subprogram of the same name but without
BIND(C,NAME="name").
A very long explanation for a one-line fix, sorry. In short, change
the code to look up the name but not resolve it at that point.
Differential Revision: https://reviews.llvm.org/D126149
Semantics was allowing calls to CHARACTER(*) functions, which are odd
things -- they can be declared, and passed around, but can never actually
be called as such. They must be redeclared with an explicit length that
ends up being passed as a hidden argument. So check for these calls
and diagnose them, add tests, and clean up some existing tests that
were in error and now get caught.
Possible TODO for lowering: there were some test cases that used
bad calls to assumed-length CHARACTER*(*) functions and validated
their implementations. I've removed some, and adjusted another,
but the code that somehow implemented these calls may need to be
removed and replaced with an assert about bad semantics.
Differential Revision: https://reviews.llvm.org/D126148
The code in semantics that reinitializes symbol table pointers in
the parse tree of a parameterized derived type prior to a new
instantiation of the type was processing the symbols of the
derived type instantiation scope in arbitrary address order,
which could fail if a reference to a type parameter inherited from
an ancestor type was processed prior to the parent component sequence.
Fix by instantiating components of PDT instantiations in declaration
order.
Differential Revision: https://reviews.llvm.org/D126147
A dummy argument in an entry point of a subprogram with multiple
entry points need not be defined in other entry points. It is only
legal to reference such an argument when calling an entry point that
does have a definition. An entry point without such a definition
needs a local "substitute" definition sufficient to generate code.
It is nonconformant to reference such a definition at runtime.
Most such definitions and associated code will be deleted as dead
code at compile time. However, that is not always possible, as in
the following code. This code is conformant if all calls to entry
point ss set m=3, and all calls to entry point ee set n=3.
subroutine ss(a, b, m, d, k) ! no x, y, n
integer :: a(m), b(a(m)), m, d(k)
integer :: x(n), y(x(n)), n
integer :: k
1 print*, m, k
print*, a
print*, b
print*, d
if (m == 3) return
entry ee(x, y, n, d, k) ! no a, b, m
print*, n, k
print*, x
print*, y
print*, d
if (n /= 3) goto 1
end
integer :: xx(3), yy(5), zz(3)
xx = 5
yy = 7
zz = 9
call ss(xx, yy, 3, zz, 3)
call ss(xx, yy, 3, zz, 3)
end
Lowering currently generates fir::UndefOp's for all unused arguments.
This is usually ok, but cases such as the one here incorrectly access
unused UndefOp arguments for m and n from an entry point that doesn't
have a proper definition.
The problem is addressed by creating a more complete definition of an
unused argument in most cases. This is implemented in large part by
moving the definition of an unused argument from mapDummiesAndResults
to mapSymbolAttributes. The code in mapSymbolAttributes then chooses
one of three code generation options, depending on information
available there.
This patch deals with dummy procedures in alternate entries, and adds
a TODO for procedure pointers (the PFTBuilder is modified to analyze
procedure pointer symbol so that they are not silently ignored, and
instead hits proper TODOs).
BoxAnalyzer is also changed because assumed-sized arrays were wrongfully
categorized as constant shape arrays. This had no impact, except when
there were unused entry points.
Co-authored-by: jeanPerier <jperier@nvidia.com>
Differential Revision: https://reviews.llvm.org/D125867
When a Hollerith (or short character) literal is presented as an actual
argument that corresponds to a dummy argument for which a BOZ literal
would be acceptable, treat the Hollerith as if it had been a BOZ
literal in the same way -- and with the same code -- as f18 already
does for the similar extension in DATA statements.
Differential Revision: https://reviews.llvm.org/D126144
Now that the requirements and implementation of asynchronous I/O are
better understood, adjust their I/O runtime APIs. In particular:
1) Remove the BeginAsynchronousOutput/Input APIs; they're not needed,
since any data transfer statement might have ASYNCHRONOUS= and
(if ASYNCHRONOUS='YES') ID= control list specifiers that need to
at least be checked.
2) Add implementations for BeginWait(All) to check for the error
case of a bad unit number and nonzero ID=.
3) Rearrange and comment SetAsynchronous so that it's clear that
it can be called for READ/WRITE as well as for OPEN.
The implementation remains completely synchronous, but should be conforming.
Where opportunities make sense for true asynchronous implementations of
some big block transfers without SIZE= in the future, we'll need to add
a GetAsynchronousId API to capture ID= on a READ or WRITE; add sourceFile
and sourceLine arguments to BeginWait(All) for good error reporting;
track pending operations in unit.h; and add code to force synchronization
to non-asynchronous I/O operations.
Lowering should call SetAsynchronous when ASYNCHRONOUS= appears as
a control list specifier. It should also set ID=x variables to 0
until such time as we support asynchronous operations, if ever.
This patch only removes the removed APIs from lowering.
Differential Revision: https://reviews.llvm.org/D126143
Forward references to ENTRY names to pass them as actual procedure arguments
don't work in all cases, exposing some basic ordering problems in
name resolution for these symbols. Refactor; create all the
necessary procedure symbols, and either function result or host association
symbols (for subroutines), at the time that the subprogrma scope is
created, so that the names exist in the scope as text "before"
the ENTRY is processed in name resolution. Some processing
remains in PostEntryStmt() so that we can check that an ENTRY with
an explicit distinct RESULT doesn't also have declarations for the
ENTRY name.
Differential Revision: https://reviews.llvm.org/D126142
The binding names of inner procedures with BIND(C) are not exposed
to the loader and should be ignored for potential conflict errors.
Differential Revision: https://reviews.llvm.org/D126141
Intrinsic module names are not in the user's namespace, so they
are free to declare global names that conflict with intrinsic
modules.
Differential Revision: https://reviews.llvm.org/D126140
For the program provided as the test case flang fired the following
error:
error: Semantic errors in main.f90
error: 'foo' is not a procedure
This change fixes the error by postponing handling of `UseErrorDetails`
from `CharacterizeProcedure` to a later stage.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D125791
The types of lower bound, upper bound, and step are converted into the
type of the loop variable if necessary. OpenMP runtime requires 32-bit
or 64-bit loop variables. OpenMP loop iteration variable cannot have
more than 64 bits size and will be narrowed.
This patch is part of upstreaming code from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project. (#1256)
Co-authored-by: kiranchandramohan <kiranchandramohan@gmail.com>
Reviewed By: kiranchandramohan, shraiysh
Differential Revision: https://reviews.llvm.org/D125740
When parallel is used in a combined construct, then use a separate
function to create the parallel operation. It handles the parallel
specific clauses and leaves the rest for handling at the inner
operations.
Reviewed By: peixin, shraiysh
Differential Revision: https://reviews.llvm.org/D125465
Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: Nimish Mishra <neelam.nimish@gmail.com>
This patch basically extends https://reviews.llvm.org/D122008 with
support for MacOSX/Darwin.
To facilitate this, I've added `MacOSX` to the list of supported OSes in
Target.cpp. Flang already supports `Darwin` and it doesn't really do
anything OS-specific there (it could probably safely skip checking the
OS for now).
Note that generating executables remains hidden behind the
`-flang-experimental-exec` flag. Also, we don't need to add `-lm` on
MacOSX as `libm` is effectively included in `libSystem` (which is linked
in unconditionally).
Differential Revision: https://reviews.llvm.org/D125628
Convert Fortran parse-tree into MLIR for collapse-clause.
Includes simple Fortran to LLVM-IR test, with auto-generated
check-lines (some of which have been edited by hand).
Reviewed By: kiranchandramohan, shraiysh, peixin
Differential Revision: https://reviews.llvm.org/D125302
As Fortran 2018 15.8.1(3), in a reference to an elemental procedure, if
any argument is an array, each actual argument that corresponds to an
INTENT (OUT) or INTENT (INOUT) dummy argument shall be an array. Add
this semantic check.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D125685
This supports the lowering parse-tree to MLIR for ordered clause in
worksharing-loop directive. Also add the test case for operation
conversion.
Part of this patch is from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.
Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
Reviewed By: kiranchandramohan, NimishMishra
Differential Revision: https://reviews.llvm.org/D125456
This patch re-factors the driver code in LLVM Flang (frontend +
compiler) to use the MLIR style. For more context, please see:
https://discourse.llvm.org/t/rfc-coding-style-in-the-driver/
Most changes here are rather self-explanatory. Accessors are renamed to
be more consistent with the rest of LLVM (e.g. allSource -->
getAllSources). Additionally, MLIR clang-tidy files are added in the
affected directories.
clang-tidy and clang-format files were copied from MLIR. Small
additional changes are made to silence clang-tidy/clang-format
warnings.
[1] https://mlir.llvm.org/getting_started/DeveloperGuide/
Differential Revision: https://reviews.llvm.org/D125007
The warning caused build errors on a couple flang testers that are
building with -Werror. The diagnostic change makes the generated
error correct.
This is a followup to https://reviews.llvm.org/D125549
Differential Revision: https://reviews.llvm.org/D125587
The predicate that is used to detect an invalid assumed-size argument
to the intrinsic functions SHAPE, SIZE, & LBOUND gives false results
for arguments whose shapes are not calculatable at compilation time.
Replace with an explicit test for an assumed-size array dummy argument
symbol.
Differential Revision: https://reviews.llvm.org/D125342
Complex component references (z%RE, z%IM) of complex named constants
should be evaluated at compilation time.
Differential Revision: https://reviews.llvm.org/D125341
Inquiries into the bounds, size, and length of local variables (and function results)
are acceptable specification expressions. A recent change allowed them for dummy
arguments that are not OPTIONAL or INTENT(OUT), but didn't address other object
entities.
Differential Revision: https://reviews.llvm.org/D125343
Fortran 2018 requires that a compiler allow objects whose rank + corank
is 15, and that's our maximum; detect and diagnose violations.
Differential Revision: https://reviews.llvm.org/D125153
Evaluate real-valued references to the intrinsic functions MODULO
and MOD at compilation time without recourse to an external math
library.
Differential Revision: https://reviews.llvm.org/D125151
Fold references to the intrinsic function DIM with constant real
arguments. And clean up folding of comparisons with NaNs to address
a problem noticed in testing -- NaNs should successfully compare
unequal to all values, including themselves, instead of failing all
comparisons.
Differential Revision: https://reviews.llvm.org/D125146
This patch adds lowering for task construct from Fortran to
`omp.task` operation in OpenMPDialect Dialect (mlir). Also added tests
for the same.
Reviewed By: kiranchandramohan, peixin
Differential Revision: https://reviews.llvm.org/D124138
In a function, ENTRY E without an explicit RESULT() creates a
function result entity also named E that is storage associated with
the enclosing function's result. f18 was emitting an incorrect error
message if that function result E was referenced without any
declaration prior to its ENTRY statement when it should have been
implicitly declared instead.
Differential Revision: https://reviews.llvm.org/D125144
As is already supported for dummy procedures, we need to also accept
declarations of procedure pointers that consist of a POINTER attribute
statement followed by an INTERFACE block. (The case of an INTERFACE
block followed by a POINTER statement already works.)
While cleaning this case up, adjust the utility predicate IsProcedurePointer()
to recognize it (namely a SubprogramDetails symbol with Attr::POINTER)
and delete IsProcName(). Extend tests, and add better comments to
symbol.h to document the two ways in which procedure pointers are
represented.
Differential Revision: https://reviews.llvm.org/D125139
The semantic test for an intrinsic assignment to a polymorphic
derived type entity from a type that is an extension of its base
type was reversed, so it would allow assignments that it shouldn't
and disallowed some that it should; and the test case for it
incorectly assumed that the invalid semantics were correct.
Fix the code and the test, and add a new test for the invalid
case (LHS type is an extension of the RHS type).
Differential Revision: https://reviews.llvm.org/D125135
The rules in the Fortran standard for specification expressions
are full of special cases and exceptions, and semantics didn't get
them exactly right. It is valid to refer to an INTENT(OUT) dummy
argument in a specification expression in the context of a
specification inquiry function like SIZE(); it is not valid to
reference an OPTIONAL dummy argument outside of the context of
PRESENT. This patch makes the specification expression checker
a little context-sensitive about whether it's examining an actual
argument of a specification inquiry intrinsic function or not.
Differential Revision: https://reviews.llvm.org/D125131
DATA statements in inner procedures were not treating undeclared objects
as implicitly declared variables if the DATA statement appeared in a
specification part; they were treated as host-associated symbols instead.
This was incorrect. Fix DATA statement name resolution to always treat
DATA as if it had appeared in the executable part.
Differential Revision: https://reviews.llvm.org/D125129
A disassociated procedure pointer is allowed to be passed as an absent
actual argument that corresponds to an optional dummy procedure,
but not NULL(); accept that case as well.
Differential Revision: https://reviews.llvm.org/D125127
The type compatibility checks for the ARRAY= argument and the dummy
arguments and result of the OPERATION= argument to the REDUCE intrinsic
function need to allow for parameterized data types with LEN parameters.
(Their values are required to be identical but this is not a numbered
constraint requiring a compilation time check).
Differential Revision: https://reviews.llvm.org/D125124
Functions returning ALLOCATABLE or POINTER arrays have descriptor inquiries in
their results' shape expressions that won't compare equal. These functions
need only be checked for compatible ranks (& of course other characteristics).
Differential Revision: https://reviews.llvm.org/D125123
Structure contructors for instances of parameterized derived types
must have their components' values folded in the context of the values
of the type parameters.
Differential Revision: https://reviews.llvm.org/D125116
Actual arguments whose lengths are less than the expected length
of their corresponding dummy argument are errors; but this needs
to be refined. Short actual arguments that are variables remain
errors, but those that are expressions can be (again) extended on
the right with blanks.
Differential Revision: https://reviews.llvm.org/D125115
The construction of the dimension order vector used to populate the
result array was incorrect, leading to a scrambled-looking result
for rank-3 and higher results. Fix, and extend tests.
Differential Revision: https://reviews.llvm.org/D125113
The standard requires that the operands of the intrinsic function
SIGN() must have the same type (INTEGER or REAL), but they are not
required to have the same kind.
Differential Revision: https://reviews.llvm.org/D125105
The related real number system inquiry functions SPACING()
and RRSPACING() can be folded for constant arguments.
See 16.9.164 & 16.9.180 in Fortran 2018.
Differential Revision: https://reviews.llvm.org/D125100
When the result can be known at compilation time, fold it.
Success depends on whether the operands are polymorphic.
When neither one is polymorphic, the result is known and can
be either .TRUE. or .FALSE.; when either one is polymorphic,
a .FALSE. result still can be discerned.
Differential Revision: https://reviews.llvm.org/D125062
Peter Klausler