There's a few (3) cases where Fortran allows two distinct symbols to have
the same name in the same scope. Module file output copes with only two of
them. The third involves a separate module procedure that isn't separate:
both the procedure and its declared interface appear in the same (sub)module.
Fix to ensure that the interface is included in the module file output, so
that the module file reader doesn't suffer a bogus error about a "separate
module procedure without an interface".
Differential Revision: https://reviews.llvm.org/D127784
A message has a %s string substitution in it but somebody (probably me)
forgot to pass the argument that defines it.
Differential Revision: https://reviews.llvm.org/D127794
The predicate that determines image control statements needs
to distinguish STOP (which is) from ERROR STOP (which isn't).
Differential Revision: https://reviews.llvm.org/D127796
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
Fix some mismatch in format used in the file and reduce the diff with fir-dev
to be able to finish the upstreaming on this file.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D127849
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
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D127738
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Lowering was crashing with "fatal internal error: node has not been analyzed"
if a PDT with initial component value was defined inside an internal
procedure. This is because the related expression cannot be analyzed
without the component values (which happens at the instatiation).
These expression do not need to be visited (the instantiations, if any
will be). Use the form of GetExpr that tolerates the parse tree expression
to not be analyzed into an evaluate::Expr when looking through the
symbols used in an internal procedure.
Note that the PDTs TODO will then fire (it happens after the PFT
analysis) as expected if the derived type is used.
Differential Revision: https://reviews.llvm.org/D127735
Codegen does not support fir.addressof of functions returning derived
types, arrays are descriptors inside GlobalOp region.
This is because the abstract-result-opt is required to rewrite such
functions (a hidden argument must be added), but this pass is meant to
run in GlobalOp currently.
Such fir.address_of may be created when lowering procedure pointers
initial value (TODO), or when creating derived type descriptors for
types with bindings.
Add a TODO in lowering until abstract-result-opt is modified to run
on GlobalOp too.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D127722
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
f18 was treating "f() = 1" as a statement function definition
if it could be viewed as being in the specification part and
"f" was a USE-associated function returning a data pointer.
(The non-USE-associated case is fine.) Fix to allow for "f"
to be USE associated.
Differential Revision: https://reviews.llvm.org/D127430
Handle the case of a non-generic procedure that is USE associated
into a scope that has a generic interface of the same name with an
appropriate error rather than crashing.
Differential Revision: https://reviews.llvm.org/D127429
FIR models Fortran intrinsic types with deliberate KIND values. Like
Fortran, COMPLEX and REAL have related KINDs in FIR. Lowering now
converts REAL types to floating point (MLIR) up front. This patch moves
the code to convert from FIR RealType to MLIR FloatType out of codegen
and into the builder, allowing FIR ComplexTypes to have their element
type returned as an MLIR FloatType.
We should consider whether to replace fir::ComplexType with
mlir::ComplexType at some point. I believe these types are presently
used to convey distinctins in the target ABIs in the Tilikum bridge
however.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D127636
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D127634
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
The scope model used for branch target checking treats a label
on an END SELECT statement as if it were in the previous CASE block.
This makes it illegal to GO TO that label from within any earlier
CASE block in that statement. Fix by treating the CASE blocks as
nested scopes within the scope of the SELECT construct.
Also, add a "warning:" tag to related warning messages.
Differential Revision: https://reviews.llvm.org/D127425
Add TODO for KIND=2 so the user is notified correctly.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D127619
Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
Loop variables of a worksharing loop and sequential loops in parallel
region are privatised by default. These variables are marked with
OmpPreDetermined. Skip explicit privatisation of these variables.
Note: This is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.
Reviewed By: Leporacanthicus
Differential Revision: https://reviews.llvm.org/D127249
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Mats Petersson <mats.petersson@arm.com>
Add TODO for half-precision for reduction.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D127622
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
The pass was raising TODOs when a function both had a fir.boxproc<> argument
and a fir.type<> argument (even if the fir.type<> did not contain a
fir.boxproc itself).
Prevent the TODO from firing when a fir.type<> does not actually contain
a fir.boxproc. Add the location for the remaining TODO (it will be
needed when procedure pointer components are supported in lowering).
FYI, I actually tried to just implement the TODO, but I there is a funny
issue. When creating the new fir::RecordType, since the name and context
are the same as the type being translated, fir::RecordType:get just
returns the existing type, and there is no way to change it (finalize()
does nothing since it is already finalized). So this will require to add
the ability to mutate the existing type, and I am not sure what are the
MLIR constraints here, so I escaped and left the TODO for that case.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D127633
Co-authored-by: Jean Perier <jperier@nvidia.com>
ALLOCATE statement allows reversed bounds (see Fortran 2018 9.7.1.2
point 1) in which case the extents are zero.
The same applies for the character length provided in the type spec that
can be negative. In which case the new length is zero.
Use genMaxWithZero to deal with these cases.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D127617
Co-authored-by: Jean Perier <jperier@nvidia.com>
system_clock intrinsic calls with dynamically optional arguments
Modify intrinsic system_clock calls to allow for an argument that is optional
or a disassociated pointer or an unallocated allocatable. A call with such an
argument is the same as a call that does not specify that argument.
Rename (genIsNotNull -> genIsNotNullAddr) and (genIsNull -> genIsNullAddr)
and add a use of genIsNotNullAddr.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D127616
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This patch adds code so that using bbc we are able to see an end-to-end lowering of simd construct in action.
Reviewed By: kiranchandramohan, peixin, shraiysh
Differential Revision: https://reviews.llvm.org/D125282
[flang]Add support for do concurrent
Upstreaming from fir-dev on https://github.com/flang-compiler/f18-llvm-project
Support for concurrent execution in do-loops.
A selection of tests are also added.
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D127240
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
Remove a backwards dependence from Optimizer -> Lower by moving Todo.h
to the optimizer and out of lowering.
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/D127292
* 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
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
Getting ompobject symbol is needed in multiple places and will be
needed later for the lowering of other constructs/clauses such as
copyin clause. Extract them into one function.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D127280
Move tthe function to allow its usage in the Optimizer/Builder functions.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D127295
Switch debub message to proper TODOs.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D127282
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>
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
On targets with __float128 available and distinct from long double,
use it to support more kind=16 entry points. This affects mostly
x86-64 targets. This means that more runtime entry points are
defined for lowering to call.
Delete Common/long-double.h and its LONG_DOUBLE macro in favor of
testing the standard macro LDBL_MANT_DIG.
Differential Revision: https://reviews.llvm.org/D127025
For example, FINDLOC(A,X) should convert both A and X to COMPLEX(8)
if the operands are REAL(8) and COMPLEX(4), so that comparisons
can be done without losing inforation. The current implementation
unconditionally converts X to the type of the array A.
Differential Revision: https://reviews.llvm.org/D127030