To be consistent with OpenACC and will find the tests in one single
directory for OpenMP.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D127529
The current RUN line leaves a parse-ir-error.s file around, which might
confuse the buildbots. Direct the output into the void instead (although
it would probably be better to direct it to FileCheck).
This relatively small change will allow Flang's frontend driver,
`flang-new -fc1`, to consume and parse MLIR files. Semantically (i.e.
from user's perspective) this is identical to reading LLVM IR files.
Two file extensions are associated with MLIR files: .fir and .mlir. Note
that reading MLIR files makes only sense when running one of the
code-generation actions, i.e. when using one of the following action
flags: -S, -emit-obj, -emit-llvm, -emit-llvm-bc.
The majority of tests that required `tco` to run are updated to also run
with `flang-new -fc1`. A few tests are updated to use `fir-opt` instead
of `tco` (that's the preferred choice when testing a particular MLIR
pass). basic-program.fir is not updated as that test is intended to
verify the behaviour of `tco` specifically.
Differential Revision: https://reviews.llvm.org/D126890
Until now, `-x` wasn't really taken into account in Flang's compiler and
frontend drivers. `flang-new` and `flang-new -fc1` only recently gained
powers to consume inputs other than Fortran files and that's probably
why this hasn't been noticed yet.
This patch makes sure that `-x` is supported correctly and consistently
with Clang. To this end, verification is added when reading LLVM IR
files (i.e. IR modules are verified with `llvm::verifyModule`). This
way, LLVM IR parsing errors are correctly reported to Flang users. This
also aids testing.
With the new functionality, we can verify that `-x ir` breaks
compilation for e.g. Fortran files and vice-versa. Tests are updated
accordingly.
Differential Revision: https://reviews.llvm.org/D127207
* Fix assertion strings.
* Fixes assertion that arose from bad FIR being constructed.
With the default member-wise component assignment, the LHS and RHS may
be compatible but distinct types. This change to lowering manages both
the LHS and RHS independently rather than assume the two types are
identical. This avoids creating bogus FIR and asserting/crashing in
codegen.
Update the tests with the member-wise copy code.
This patch is part of the upstreaming effort from fir-dev branch.
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D127297
Add a test with a range of ucobound() intrinsic function
invocations, including a comprehensive set of standard-conforming
keyword and non-keyword arguments with and without optional
arguments present and with argument positions covering all
possible orderings. Also test that several non-conforming
ucobound() invocations generate the correct error messages.
Differential Revision: https://reviews.llvm.org/D126508
Simply add a source and target materialization handler that do nothing
and that override the default handlers that would add illegal
LLVM::DialectCastOp otherwise.
This is the simplest workaround, but not an actual fix, something may be
inconsistent after D82831 (most likely fir lowering to llvm happens in a
way that mlir infrastructure is not expecting in D82831).
Here is a minimal reproducer of what the issue was:
```
func @foop(%a : !fir.real<4>) -> ()
func @bar(%a : !fir.real<2>) {
%1 = fir.convert %a : (!fir.real<2>) -> !fir.real<4>
call @foop(%1) : (!fir.real<4>) -> ()
return
}
```
tco -o - output was:
```
error: 'llvm.mlir.cast' op type must be non-index integer types, float types, or vector of mentioned types.
llvm.func @foop(!llvm.float)
llvm.func @bar(%arg0: !llvm.half) {
%0 = llvm.fpext %arg0 : !llvm.half to !llvm.float
%1 = llvm.mlir.cast %0 : !llvm.float to !fir.real<4>
llvm.call @foop(%1) : (!fir.real<4>) -> ()
llvm.return
}
```
This patch disable the introduction of the llvm.mlir.cast and preserve the previous behavior.
Also fixes https://github.com/llvm/llvm-project/issues/55210.
Note: This is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D127212
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Add support for lowering the schedule modifiers (simd, monotonic,
non-monotonic) in worksharing loops.
Note: This is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D127311
Co-authored-by: Mats Petersson <mats.petersson@arm.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This is a small follow-up for https://reviews.llvm.org/D120051. It makes
sure that tables with "run-time type information for derived types" are
generated for code-gen actions. Originally, only non-code-gen actions
were updated (i.e. actions that were fully supported at that time).
Differential Revision: https://reviews.llvm.org/D127307
As Fortran 2018 R874, common block object must be one variable name, which
cannot be one named constant. Add this check.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D126762
As Fortran 2018 C1521, in procedure declaration statement, if
proc-language-binding-spec (bind(c)) is specified, the proc-interface
shall appear, it shall be an interface-name, and interface-name shall
be declared with a proc-language-binding-spec.
Reviewed By: klausler, Jean Perier
Differential Revision: https://reviews.llvm.org/D127121
Given the flag `--always-execute-loop-body` the compiler emits code
to execute the body of the loop atleast once.
Note: This is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.
Reviewed By: awarzynski, schweitz
Differential Revision: https://reviews.llvm.org/D127128
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: Sameeran Joshi <sameeranjayant.joshi@amd.com>
A few OpenMP tests were retaining the FIR operands even after running
the LLVM conversion pass. To fix these tests the legality checkes for
OpenMP conversion are made stricter to include operands and results.
The Flush, Single and Sections operations are added to conversions or
legality checks. The RegionLessOpConversion is appropriately renamed
to clarify that it works only for operations with Variable operands.
The operands of the flush operation are changed to match those of
Variable Operands.
Fix for an OpenMP issue mentioned in
https://github.com/llvm/llvm-project/issues/55210.
Reviewed By: shraiysh, peixin, awarzynski
Differential Revision: https://reviews.llvm.org/D127092
This supports lowering parse-tree to MLIR for threadprivate directive
following the OpenMP 5.1 [2.21.2] standard. Take the following as an
example:
```
program m
integer, save :: i
!$omp threadprivate(i)
call sub(i)
!$omp parallel
call sub(i)
!$omp end parallel
end
```
```
func.func @_QQmain() {
%0 = fir.address_of(@_QFEi) : !fir.ref<i32>
%1 = omp.threadprivate %0 : !fir.ref<i32> -> !fir.ref<i32>
fir.call @_QPsub(%1) : (!fir.ref<i32>) -> ()
omp.parallel {
%2 = omp.threadprivate %0 : !fir.ref<i32> -> !fir.ref<i32>
fir.call @_QPsub(%2) : (!fir.ref<i32>) -> ()
omp.terminator
}
return
}
```
A threadprivate operation (omp.threadprivate) is created for all
references to a threadprivate variable. The runtime will appropriately
return a threadprivate var (%1 as above) or its copy (%2 as above)
depending on whether it is outside or inside a parallel region. For
threadprivate access outside the parallel region, the threadprivate
operation is created in instantiateVar. Inside the parallel region, it
is created in createBodyOfOp.
One new utility function collectSymbolSet is created for collecting
all the variables with a property within a evaluation, which may be one
Fortran, or OpenMP, or OpenACC construct.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D124226
The previous XArrayCoorOp conversion forgot to change getting the
operands from OpAdaptor for upper bound and step of slice. This leads to
the fail of incompatible of types of codegen when slices are index type.
Reviewed By: kiranchandramohan, schweitz
Differential Revision: https://reviews.llvm.org/D125967
The previous semantic analysis does not consider when the last part-ref
is scalar or complex part. Refactor the previous code and bring all the
checks into one place. The check starts from the designator by
extracting the dataref wrapped including the substring and complex part
and recursively check the base objects.
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D126595
OpenMP 5.0 adds a new clause `in_reduction` on OpenMP directives.
This patch adds parser support for the same.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D124156
In the USE statements that f18 emits to module files, ensure that symbols
from intrinsic modules are marked as such on their USE statements. And
ensure that the current working directory (".") cannot override the intrinsic
module search path when trying to locate an intrinsic module.
Differential Revision: https://reviews.llvm.org/D127019
The entity with BIND(C) attribute cannot be a named constant, so the
BIND(C) and parameter attributes are conflicted. Add check for it.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D126654
Flang is manually mangling names for memset/memcpy/memmove
intrinsics, so we need to update the mangling to use the opaque
pointer format (p0 instead of p0i8).
As per issue #1196, the loop induction variable, which is an argument
in the omp.wsloop operation, does not have a memory location, so when
passed to a function or subroutine, the reference to the value is not
a memory location, but the value of the induction variable. The callee
function/subroutine is then trying to dereference memory at address 1
or some other "not a good memory location".
This is fixed by creating a temporary memory location and storing the
value of the induction variable in that.
Test fixes as a consequence of the changed code generated.
Add checking for some of the omp-unstructured.f90 to check for alloca,
store and load operations, to ensure the correct flow. Add a test
for CYCLE inside a omp-do loop.
Also convert to use -emit-fir in the omp-unstructrued, and make
the symbol matching consistent in the omp-wsloop-variable test.
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D126711
This patch supports the following checks:
```
[5.1] 2.21.2 THREADPRIVATE Directive
The threadprivate directive must appear in the declaration section of
a scoping unit in which the common block or variable is declared.
[5.1] 2.14.7 Declare Target Directive
The directive must appear in the declaration section of a scoping unit
in which the common block or variable is declared.
```
Reviewed By: kiranchandramohan, shraiysh, NimishMishra
Differential Revision: https://reviews.llvm.org/D125767
The basic infinite loop is lowered to a branch to the body of the
loop, and the body containing a back edge as its terminator.
Note: This is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.
Reviewed By: rovka
Differential Revision: https://reviews.llvm.org/D126697
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Upstream the code for handling loops with real control variables from
the fir-dev branch at
https://github.com/flang-compiler/f18-llvm-project/tree/fir-dev/
Also add a test.
Loops with real-valued control variables are always lowered to
unstructured loops. The real-valued control variables are handled the
same as integer ones, the only difference is that they need to use
floating point instructions instead of the integer equivalents.
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Similar to procedure argument, the function result cannot be one
named constant.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D126693
As Fortran 2018 C819, a variable with the BIND attribute shall be declared
in the specification part of a module. Add the support for this check.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D126653
The following changes are made for OpenMP operations with unstructured region,
1. For combined constructs the outer operation is considered a structured
region and the inner one as the unstructured.
2. Added a condition to ensure that we create new blocks only once for nested
unstructured OpenMP constructs.
Tests are added for checking the structure of the CFG.
Note: This is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project. Code originally reviewed
at https://github.com/flang-compiler/f18-llvm-project/pull/1394.
Reviewed By: vdonaldson, shraiysh, peixin
Differential Revision: https://reviews.llvm.org/D126375
Upstream the code for handling while loops from the fir-dev branch at
https://github.com/flang-compiler/f18-llvm-project/tree/fir-dev/
Also add tests.
The while loop is lowered to a header block that checks the loop
condition and branches either to the exit block or to the body of the
loop. The body of the loop will unconditionally branch back to the
header.
Differential Revision: https://reviews.llvm.org/D126636
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This patch implements the following semantic check:
A list-item cannot appear in more than one nontemporal clause.
Reviewed By: kiranchandramohan, shraiysh
Differential Revision: https://reviews.llvm.org/D110270
Test that chunk size is passed to the static init function.
Using three different variations:
1. Single constant.
2. Expression with constants.
3. Variable value.
Reviewed By: peixin, shraiysh
Differential Revision: https://reviews.llvm.org/D126383
As an extension for REAL literals, we allow an exponent letter which
matches an explicit kind-param. The standard requires the exponent
to be 'E' if a kind-param is present. This patch
- documents this extension in Extensions.md
- enables a portability warning if it is used with -pedantic
The test case for this, kinds05.f90, needs D125804, which makes
test_errors.py test warnings as well, to actually test the warnings.
I include it already now to keep things together, it will do no harm
(I hope ...).
We also add WARNING-directives to the test kinds04.f90 in preparation
for D125804. As the exponent-letter 'Q' does not imply the same kind
on all platforms, the emitted warnings are platform-dependent.
Therefore, the test is duplicated into two variants which are run
conditionally.
Finally, we promote the portability warning for when the exponent letter
is neither 'E' nor matching the kind-param to a standard warning.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D126459
When two or more generic interfaces are available by declaration or
by USE association at different scoping levels, we need to search
the outer generic interfaces as well as the inner ones, but only after
the inner ones have failed to produce a specific procedure that matches
a given set of actual arguments. This means that it is possible for
a specific procedure of a generic interface of an inner scope to override
a conflicting specific procedure of a generic interface of an outer
scope.
Also cope with forward references to derived types when a generic
interface is also in scope.
Fixes LLVM bug https://github.com/llvm/llvm-project/issues/55240 and
LLVM bug https://github.com/llvm/llvm-project/issues/55300.
Differential Revision: https://reviews.llvm.org/D126587
When processing the literal constants of the various kinds of
INTEGER that are too large by 1 (e.g., 2147483648_4) in expression
analysis, emit a portability warning rather than a fatal error if
the literal constant appears as the operand to a unary minus, since
the folded result will be in range. And don't emit any warning if
the negated literal is coming from a module file -- f18 wrote the
module file and the warning would simply be confusing, especially to
the programmer that wrote (-2147483647_4-1) in the first place.
Further, emit portability warnings for the canonical expressions for
infinities and NaN (-1./0., 0./0., & 1./0.), but not when they appear
in a module file, for the same reason. The Fortran language has no
syntax for these special values so we have to emit expressions that
fold to them.
Fixes LLVM bugs https://github.com/llvm/llvm-project/issues/55086 and
https://github.com/llvm/llvm-project/issues/55081.
Differential Revision: https://reviews.llvm.org/D126584
For pointer variables, using getSymbolAddress cannot get the coorect
address for atomic read/write operands. Use genExprAddr to fix it.
Reviewed By: shraiysh, NimishMishra
Differential Revision: https://reviews.llvm.org/D125793
This patch cleans up the sections tests as per the recent effort to
separate integration tests from unit tests.
Reviewed By: kiranchandramohan, peixin
Differential Revision: https://reviews.llvm.org/D126368
If a line is over 72 characters long, flang's preprocessor cuts it there
and continues on the next line.
For this purpose it uses the standard way of continuing line with & on each line.
However, it doesn't work with long compiler directives, like OpenMP or OpenACC ones.
The line that continues the directive also has to
contain the corresponding sentinel at the beginning.
This change implements the described functionality.
Also, some code was refactored in order to simplify and reuse existing code.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D126301
Add a test with a range of this_image() intrinsic function
invocations, including a comprehensive set of standard-conforming
keyword and non-keyword arguments with and without optional
arguments present and with argument positions covering all
possible orderings. Also test that several non-conforming
this_image() invocations generate the correct error messages.
Differential Revision: https://reviews.llvm.org/D123331
This is a preparation for D125804, which makes test_errors.py test
warnings the same way it already tests errors, i.e., assert that the
emitted and expected errors are identical. The following changes are
made to the test:
- Add the WARNING directive where warnings are expected.
- Remove -Werror in the RUN line. It does not serve much purpose here:
with -Werror flang makes compilation fail in the presence of
warnings, but warnings are still printed as warnings and not as
errors. And I anyway find it better to test the warnings as warnings
instead of promoting them and test both warnings and errors as
errors.
- Update the header comment describing the test case, mostly in
response to the removal of -Werror.
- Remove the reference to 'issue 458', referring to
https://github.com/flang-compiler/f18/issues/458, from the header.
I think the relevant reference here is to C1120 of the standard,
and references to bug trackers from other projects (from before
upstreaming) can be confusing.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D126176
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
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 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
PeixinQiao