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 patch refines //when// driver diagnostics are formatted so that
`flang-new` and `flang-new -fc1` behave consistently with `clang` and
`clang -cc1`, respectively. This change only applies to driver diagnostics.
Scanning, parsing and semantic diagnostics are separate and not covered here.
**NEW BEHAVIOUR**
To illustrate the new behaviour, consider the following input file:
```! file.f90
program m
integer :: i = k
end
```
In the following invocations, "error: Semantic errors in file.f90" _will be_
formatted:
```
$ flang-new file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
integer :: i = k
$ flang-new -fc1 -fcolor-diagnostics file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
integer :: i = k
```
However, in the following invocations, "error: Semantic errors in file.f90"
_will not be_ formatted:
```
$ flang-new -fno-color-diagnostics file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
integer :: i = k
$ flang-new -fc1 file.f90
error: Semantic errors in file.f90
./file.f90:2:18: error: Must be a constant value
integer :: i = k
```
Before this change, none of the above would be formatted. Note also that the
default behaviour in `flang-new` is different to `flang-new -fc1` (this is
consistent with Clang).
**NOTES ON IMPLEMENTATION**
Note that the diagnostic options are parsed in `createAndPopulateDiagOpt`s in
driver.cpp. That's where the driver's `DiagnosticEngine` options are set. Like
most command-line compiler driver options, these flags are "claimed" in
Flang.cpp (i.e. when creating a frontend driver invocation) by calling
`getLastArg` rather than in driver.cpp.
In Clang's Options.td, `defm color_diagnostics` is replaced with two separate
definitions: `def fcolor_diagnostics` and def fno_color_diagnostics`. That's
because originally `color_diagnostics` derived from `OptInCC1FFlag`, which is a
multiclass for opt-in options in CC1. In order to preserve the current
behaviour in `clang -cc1` (i.e. to keep `-fno-color-diagnostics` unavailable in
`clang -cc1`) and to implement similar behaviour in `flang-new -fc1`, we can't
re-use `OptInCC1FFlag`.
Formatting is only available in consoles that support it and will normally mean that
the message is printed in bold + color.
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
Reviewed By: rovka
Differential Revision: https://reviews.llvm.org/D126164
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
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D128331
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
This patch clean up some code for upstreaming and add couple of
missing tests that were left in fir-dev.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D128258
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Add more diagnostics to fir.coordinate_of to provide better checking
that the IR is sane.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D128255
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D128186
Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
When linking a Fortran program, we need to add the runtime libraries to
the command line. This is exactly what we do for Linux/Darwin, but the
MSVC interface is slightly different (e.g. -libpath instead of -L).
We also remove oldnames and libcmt, since they're not needed at the
moment and they bring in more dependencies.
We also pass `/subsystem:console` to the linker so it can figure out the
right entry point. This is only needed for MSVC's `link.exe`. For LLD it
is redundant but doesn't hurt.
Differential Revision: https://reviews.llvm.org/D126291
Co-authored-by: Markus Mützel <markus.muetzel@gmx.de>
The upstreamed code was not incrementing the sliceOffset in multiples
of 3. This issue is fixed by using Offsets and incrementing by 3 during
every iteration.
In the conversion pattern, we were comparing the definingOp of an
operand with an FIR::UndefOp. Use LLVM::UndefOp for conversion.
Reviewed By: clementval, Leporacanthicus
Differential Revision: https://reviews.llvm.org/D128017
This patch is part of the upstreaming effort from fir-dev branch.
It also ensures all descriptors created inline complies with LBOUND
requirement that the lower bound is `1` when the related dimension
extent is zero.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D128047
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
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
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
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
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
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>
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>
A test added in https://reviews.llvm.org/D127207 is missing
target/triple. This has caused the PowerPC buildbot to start failing:
* https://lab.llvm.org/buildbot/#/builders/21/builds/42860
(on PowerPC `; CHECK: ret` should be replaced with `; CHECK: `blr`).
Sending this without a review as the fix is rather straightforward. Note
that I've decided to add triple/target instead of e.g. removing:
`; CHECK: ret`. That's for consistency with other tests that generate
assembly. We could change that if that's what folks prefer.
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
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
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
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
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
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
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
This change allows to write whitespaces before the `ERROR` keyword
in semantic tests for consistency with other testing infrastructure.
Also, one test is changed in order to test if the change works
correctly.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D125884
`-module-dir` is Flang's equivalent for `-J` from GFortran (in fact,
`-J` is an alias for `-module-dir` in Flang). Currently, only
`-module-dir <value>` is accepted. However, `-J` (and other options for
specifying various paths) accepts `-J<value>` as well as `-J <value>`.
This patch makes sure that `-module-dir` behaves consistently with other
such flags.
Differential Revision: https://reviews.llvm.org/D125957
Add a test with standard-conforming non-conforming lcobound()
intrinsic function invocations. Also test that several
non-conforming lcobound() invocations generate the correct error
messages.
Differential Revision: https://reviews.llvm.org/DD123747
Add support for reading response files in the flang driver. Response
files contain command line arguments and are used whenever a command
becomes longer than the shell/environment limit. Response files are
recognized via the special "@path/to/response/file.rsp" syntax, which
distinguishes them from other file inputs.
This patch hardcodes GNU tokenization, since we don't have a CL mode for
the driver. In the future we might want to add a --rsp-quoting command
line option, like clang has, to accommodate Windows platforms.
Differential Revision: https://reviews.llvm.org/D124846
The previous fix from af371f9f98 only applied when using a bottom-up
traversal. The change here applies the constant preprocessing logic to the
top-down case as well. This resolves the issue with the canonicalizer pass still
reordering constants, since it uses a top-down traversal by default.
Fixes#51892
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D125623
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 was carry over from LLVM IR where the alias definition can
be ambiguous, but MLIR type aliases have no such problems.
Having the `type` keyword is superfluous and doesn't add anything.
This commit drops it, which also nicely aligns with the syntax for
attribute aliases (which doesn't have a keyword).
Differential Revision: https://reviews.llvm.org/D125501
Complex component references (z%RE, z%IM) of complex named constants
should be evaluated at compilation time.
Differential Revision: https://reviews.llvm.org/D125341
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
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
When processing an entry-stmt in name resolution, attrs_ was
reset before SetBindNameOn was called, causing the symbol to lose
the binding label information.
Differential Revision: https://reviews.llvm.org/D125097
As Fortran 2018 5.2.2 states, a program shall consist of exactly one
main program. Add this semantic check.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D125186
This was leftover from when the standard dialect was destroyed, and
when FuncOp moved to the func dialect. Now that these transitions
have settled a bit we can drop these.
Most updates were handled using a simple regex: replace `^( *)func` with `$1func.func`
Differential Revision: https://reviews.llvm.org/D124146
The code below causes flang to crash with an exception.
After fixing the crash flang with an internal error "no symbol found for 'bar'"
This change fixes all the issues.
program name
implicit none
integer, parameter :: bar = 1
integer foo(bar) /bar*2/
end program name
Reviewed By: kiranchandramohan, klausler
Differential Revision: https://reviews.llvm.org/D124914
As Fortran 2018 states, in each where-assignment-stmt, the mask-expr and
the variable being defined shall be arrays of the same shape. The
previous check does not consider checking if it is an array.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D125022
As Fortran 2018 15.5.2.9 point 2, the actual argument and dummy argument
have the same type and type parameters and an external function with
assumed character length may be associated with a dummy argument with
explicit character length. As Fortran 2018 15.5.2.9 point 7, if an
external procedure is used as an actual argument, it can be explicitly
declared to have the EXTERNAL attribute. This supports the external
procedure passed as actual argument with implicit character type, either
explicit character length or assumed character length.
Reviewed By: Jean Perier, klausler
Differential Revision: https://reviews.llvm.org/D124345
For arrays without a constant interior or arrays of character with
dynamic length arrays, the data types are converted to a pointer to the
element type, so the scale size of the constant extents needs to be
counted. The previous AllocaOp conversion does not consider the arrays
of character with dynamic length arrays, and the previous AllocMemOp
conversion does not consider arrays without a constant interior. This
fixes them and refactors the code so that it can be shared. Also add
the test cases.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D124766
The OpenMP worksharing loop operation in the dialect is a proper loop
operation and not a container of a loop. So we have to lower the
parse-tree OpenMP loop construct and the do-loop inside the construct
to a omp.wsloop operation and there should not be a fir.do_loop inside
it. This is achieved by skipping fir.do_loop creation and calling genFIR
for the nested evaluations in the lowering of the do construct.
Note: Handling of more clauses, parallel do, storage of loop index variable etc will come in separate patches.
Part of the upstreaming effort to move LLVM Flang from fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project to the LLVM Project.
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D125024
Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
Co-authored-by: Shraiysh Vaishay <Shraiysh.Vaishay@amd.com>
The FIR `do_loop` is designed as a structured operation with a single
block inside it. Presence of unstructured constructs like jumps, exits
inside the loop will cause the loop to be marked as unstructured. These
loops are lowered using the `control-flow` dialect branch operations.
Fortran semantics do not allow the loop variable to be modified inside
the loop. To prevent accidental modification, the iteration of the
loop is modeled by two variables, trip-count and loop-variable.
-> The trip-count and loop-variable are initialized in the pre-header.
The trip-count is set as (end-start+step)/step where end, start and
step have the usual meanings. The loop-variable is initialized to start.
-> The header block contains a conditional branch instruction which
selects between branching to the body of the loop or the exit block
depending on the value of the trip-count.
-> Inside the body, the trip-count is decremented and the loop-variable
incremented by the step value. Finally it branches to the header of the
loop.
Part of the upstreaming effort to move LLVM Flang from fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project to the LLVM Project.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D124837
Co-authored-by: Val Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
This patch adds support for `-save-temps` in `flang-new`, Flang's
compiler driver. The semantics of this option are inherited from Clang.
The file extension for temporary Fortran preprocessed files is set to
`i`. This is identical to what Clang uses for C (or C++) preprocessed
files. I have tried researching what other compilers do here, but I
couldn't find any definitive answers. One GFortran thread [1] suggests
that indeed it is not clear what the right approach should be.
Normally, various phases in Clang/Flang are combined. The `-save-temps`
option works by forcing the compiler to run every phase separately. As
there is no integrated assembler driver in Flang, user will have to use
`-save-temps` together with `-fno-integrated-as`. Otherwise, an
invocation to the integrated assembler would be generated generated,
which is going to fail (i.e. something equivalent to `clang -cc1as` from
Clang).
There are no specific plans for implementing an integrated assembler for
Flang for now. One possible solution would be to share it entirely with
Clang.
Note that on Windows you will get the following error when using
`-fno-integrated-as`:
```bash
flang-new: error: there is no external assembler that can be used on this platform
```
Unfortunately, I don't have access to a Windows machine to investigate
this. Instead, I marked the tests in this patch as unsupported on
Windows.
[1] https://gcc.gnu.org/bugzilla//show_bug.cgi?id=81615
Differential Revision: https://reviews.llvm.org/D124669
This seems to be the consensus in
https://github.com/flang-compiler/f18-llvm-project/issues/1316
The patch adds ExternalNameConversion to the default FIR CodeGen pass
pipeline, right before the FIRtoLLVM pass. It also adds a flag to
optionally disable it, and sets it in `tco`. In other words, `flang-new`
and `flang-new -fc1` will both run the pass by default, whereas `tco`
will not, so none of the tests need to be updated.
Differential Revision: https://reviews.llvm.org/D121171
The fallback attribute parse path is parsing a Type attribute, but this results
in a really unintuitive error message: `expected non-function type`, which
doesn't really hint at tall that we were trying to parse an attribute. This
commit fixes this by trying to optionally parse a type, and on failure
emitting an error that we were expecting an attribute.
Differential Revision: https://reviews.llvm.org/D124870
In https://reviews.llvm.org/D124667, I added tests that check the
generated assembly. I verified the assembly on AArch64 and X86_64, but
the PPC Flang buildbot [1] started failing (i.e. the assembly was not
generic enough).
In order to fix this, I'm changing these tests to be only run on
AAarch64 - that's the architecture that most of public Flang buildbots
use.
I'm hoping that this is straightforward enough and am merging it without
a review.
[1] https://lab.llvm.org/buildbot/#/builders/21/builds/40256
This change makes sure that Flang's driver recognises LLVM IR and BC as
supported file formats. To this end, `isFortran` is extended and renamed
as `isSupportedByFlang` (the latter better reflects the new
functionality).
New tests are added to verify that the target triple is correctly
overridden by the frontend driver's default value or the value specified
with `-triple`. Strictly speaking, this is not a functionality that's
new in this patch (it was added in D124664). This patch simply enables
us to write such tests and hence I'm including them here.
Differential Revision: https://reviews.llvm.org/D124667
When we pass an alternate return specifier to a regular (not an asterisk)
dummy argument, flang would throw an internal compiler error of
derefencing a null pointer.
To avoid the ICE, a check was added.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D123947
The RETURN statement is allowed in functions and subroutines, but not
in main programs. It is however a common extension, which we also
implement, to allow RETURN from main programs -- we only issue a
portability warning when -pedantic or -std=f2018 are set.
This patch fixes false positives for this portability warning, where it
was triggered also when RETURN was present in functions or subroutines.
Fixexs #55080
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D124732
This patch restricts the value of `if` clause expression to an I1 value.
It also restricts the value of `num_threads` clause expression to an I32
value.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D124142
As Fortran 2018 C1533, a nonintrinsic elemental procedure shall not be
used as an actual argument. The semantic check for implicit iterface is
missed.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D124379
Semantics is not preventing a named common block to appear with
different size in a same file (named common block should always have
the same storage size (see Fortran 2018 8.10.2.5), but it is a common
extension to accept different sizes).
Lowering was not coping with this well, since it just use the first
common block appearance, starting with BLOCK DATAs to define common
blocks (this also was an issue with the blank common block, which can
legally appear with different size in different scoping units).
Semantics is also not preventing named common from being initialized
outside of a BLOCK DATA, and lowering was dealing badly with this,
since it only gave an initial value to common blocks Globals if the
first common block appearance, starting with BLOCK DATAs had an initial
value.
Semantics is also allowing blank common to be initialized, while
lowering was assuming this would never happen, and was never creating
an initial value for it.
Lastly, semantics was not complaining if a COMMON block was initialized
in several scoping unit in a same file, while lowering can only generate
one of these initial value.
To fix this, add a structure to keep track of COMMON block properties
(biggest size, and initial value if any) at the Program level. Once the
size of a common block appearance is know, the common block appearance
is checked against this information. It allows semantics to emit an error
in case of multiple initialization in different scopes of a same common
block, and to warn in case named common blocks appears with different
sizes. Lastly, this allows lowering to use the Program level info about
common blocks to emit the right GlobalOp for a Common Block, regardless
of the COMMON Block appearances order: It emits a GlobalOp with the
biggest size, whose lowest bytes are initialized with the initial value
if any is given in a scope where the common block appears.
Lowering is updated to go emit the common blocks before anything else so
that the related GlobalOps are available when lowering the scopes where
common block appear. It is also updated to not assume that blank common
are never initialized.
Differential Revision: https://reviews.llvm.org/D124622
This patch adds code to lower simple Fortran Do loops with loop control.
Lowering is performed by the the `genFIR` function when called with a
`Fortran::parser::DoConstruct`. `genFIR` function calls `genFIRIncrementLoopBegin`
then calls functions to lower the body of the loop and finally calls
the function `genFIRIncrementLoopEnd`. `genFIRIncrementLoopBegin` is
responsible for creating the FIR `do_loop` as well as storing the value of
the loop index to the loop variable. `genFIRIncrementLoopEnd` returns
the incremented value of the loop index and also stores the index value
outside the loop. This is important since the loop variable can be used
outside the loop. Information about a loop is collected in a structure
`IncrementLoopInfo`.
Note 1: Future patches will bring in lowering for unstructured,
infinite, while loops
Note 2: This patch is part of upstreaming code from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D124277
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Val Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Previously MASK= elements were accessed in assumption that mask is an array of
input argument rank (and in combination with explicit DIM= argument we had
out-of-bounds access), but for MAXLOC/MINLOC/FINDLOC mask should be be
conformable and could be scalar.
Add new regression tests with scalar mask for verification.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D124408
This patch provides the basic infrastructure for lowering declarative
constructs for OpenMP and OpenACC.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: kiranchandramohan, shraiysh, clementval
Differential Revision: https://reviews.llvm.org/D124225
A non-CHARACTER expression in a CASE statement is allowed to have
a distinct kind (not type) from the expression in its SELECT CASE.
If a value in a CASE statement is out of range for the SELECT CASE
type, emit a warning, but it should not be a fatal error.
Differential Revision: https://reviews.llvm.org/D124544
Similarly to LBOUND in https://reviews.llvm.org/D123237, fix UBOUND() folding
for constant arrays (for both w/ and w/o DIM=): convert
GetConstantArrayLboundHelper into common helper class for both lower/upper
bounds.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D123520
Lowering of FailImage statement generates a runtime call and the
unreachable operation. The unreachable operation cannot terminate
a structured operation like the IF operation, hence mark as
unstructured.
Note: This patch is part of upstreaming code from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D124520
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
At the top level of program units in a source file, two subprograms
are allowed to have the same name if at least one of them has a
distinct interoperable binding name. F18's symbol table requires
(most) symbols in a scope to have distinct names, though. Solve
by using compiler-created names for the symbols of global scope
subprograms that have interoperable binding names.
Differential Revision: https://reviews.llvm.org/D124295
This patch adds 2 missing items required for `flang-new` to be able to
generate executables:
1. The Fortran_main runtime library, which implements the main entry
point into Fortran's `PROGRAM` in Flang,
2. Extra linker flags to include Fortran runtime libraries (e.g.
Fortran_main).
Fortran_main is the bridge between object files generated by Flang and
the C runtime that takes care of program set-up at system-level. For
every Fortran `PROGRAM`, Flang generates the `_QQmain` function.
Fortran_main implements the C `main` function that simply calls
`_QQmain`.
Additionally, "<driver-path>/../lib" directory is added to the list of
search directories for libraries. This is where the required runtime
libraries are currently located. Note that this the case for the build
directory. We haven't considered installation directories/targets yet.
With this change, you can generate an executable that will print `hello,
world!` as follows:
```bash
$ cat hello.f95
PROGRAM HELLO
write(*, *) "hello, world!"
END PROGRAM HELLO
$ flang-new -flang-experimental-exec hello.f95
./a.out
hello, world!
```
NOTE 1: Fortran_main has to be a static library at all times. It invokes
`_QQmain`, which is the main entry point generated by Flang for the
given input file (you can check this with `flang-new -S hello.f95 -o - |
grep "Qmain"`). This means that Fortran_main has an unresolved
dependency at build time. The linker will allow this for a static
library. However, if Fortran_main was a shared object, then the linker
will produce an error: `undefined symbol: `_QQmain`.
NOTE 2: When Fortran runtime libraries are generated as shared libraries
(excluding Fortran_main, which is always static), you will need to
tell the dynamic linker (by e.g. tweaking LD_LIBRARY_PATH) where to look
for them when invoking the executables. For example:
```bash
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<flang-build-dir>/lib/ ./a.out
```
NOTE 3: This feature is considered experimental and currently guarded
with a flag: `-flang-experimental-exec`.
Differential Revision: https://reviews.llvm.org/D122008
[1] https://github.com/flang-compiler/f18-llvm-project
CREDITS: Fortran_main was originally written by Eric Schweitz, Jean
Perier, Peter Klausler and Steve Scalpone in the fir-dev` branch in [1].
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Steve Scalpone <sscalpone@nvidia.com
The lowering code was mistakenly assuming that the second argument
in the signature provided by semantics is the DIM argument. This
caused calls with a KIND argument but no DIM to be lowered as if the
KIND argument was DIM.
Differential Revision: https://reviews.llvm.org/D124243
In some case the lowering of `ichar` is generating an `arith.extui` operation
with the same from/to type. This operation do not accept from/to types to be
the same. If the from/to types are identical, we do not generate the extra
operation.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D124107
Transformational bessel intrinsic functions require the same math runtime
as elemental bessel intrinsics.
Currently elemental bessels could be folded if f18 was linked with pgmath
(cmake -DLIBPGMATH_DIR option). `j0`, `y0`, ... C libm functions were not
used because they are not standard C functions: they are Posix
extensions.
This patch enable:
- Using the Posix bessel host runtime functions when available.
- folding the transformational bessel using the elemental version.
Differential Revision: https://reviews.llvm.org/D124167
The following code causes the compiler to ICE in several places due to
lack of support of recursive procedure definitions through the function
result.
function foo() result(r)
procedure(foo), pointer :: r
end function foo
This patch adds lowering support for atomic read and write constructs.
Also added is pointer modelling code to allow FIR pointer like types to
be inferred and converted while lowering.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D122725
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
This patch handles empty hint value for critical and atomic constructs.
This also adds checks and tests for hint clause on atomic constructs.
Reviewed By: peixin, kiranchandramohan, NimishMishra
Differential Revision: https://reviews.llvm.org/D123186
When known at compile time, Ew.d and Dw.d output edit descriptors
should respect limitations from the standard on the value of a
kP scale factor with respect to the digit count (d), at least for
values of k other than zero.
Set LBOUND() constant folding for parentheses expr. as ones
Array bounds should not propagate throught omitted bounds specifications or
temporary variables - fix constant folding in case of Parentheses<T> expression
by explicitly returning array of ones (or scalar in case of DIM=).
Add set of tests for (x) bounds checks (w/ and w/o 'parameter' arrays)
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D123838
Previously constant folding uses 'dim' without checks which leads to ICE if we
do not have DIM= parameter. And for inputs without DIM= we need to form an
array of rank size with computed bounds instead of single value.
Add additional PackageConstant function to simplify 'if (dim)' handling since we
need to distinguish between scalar initialization in case of DIM= argument and
rank=1 array.
Also add a few more tests with 'parameter' type to verify folding for constant
arrays.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D123237
A missing "!" in the call interface lowering caused all derived type
arguments without length parameters that require and explicit interface
to be passed via fir.box (runtime descriptor).
This was not the intent: there is no point passing a simple derived type
scalars or explicit shapes by descriptor just because they have an attribute
like TARGET. This would actually be problematic with existing code that is
not always 100% compliant: some code implicitly calls procedures with
TARGET dummy attributes (this is not something a compiler can enforce
if the call and procedure definition are not in the same file).
Add a Scope::IsDerivedTypeWithLengthParameter to avoid passing derived
types with only kind parameters by descriptor. There is no point, the
callee knows about the kind parameter values.
Differential Revision: https://reviews.llvm.org/D123990
A POINTER attribute statement is allowed to add the POINTER attribute
to a procedure entity that has already been declared, e.g. with an
INTERFACE block.
Differential Revision: https://reviews.llvm.org/D123732
f18 was emitting a warning about short character actual arguments to
subprograms and statement functions; every other compiler considers this
case to be an error.
Differential Revision: https://reviews.llvm.org/D123731
For parameterized derived type component initializers whose
expressions' types depend on parameter values, f18's current
scheme of analyzing the initialization expression once during
name resolution fails. For example,
type :: pdt(k)
integer, kind :: k
real :: component = real(0.0, kind=k)
end type
To handle such cases, it is necessary to re-analyze the parse
trees of these initialization expressions once for each distinct
initialization of the type.
This patch adds code to wipe an expression parse tree of its
typed expressions, and update those of its symbol table pointers
that reference type parameters, and then re-analyze that parse
tree to generate the properly typed component initializers.
Differential Revision: https://reviews.llvm.org/D123728
When a procedure pointer or procedure dummy argument has a
defined interface, the rank of the pointer (or dummy) is the
rank of the interface.
Also tweak code discovered in shape analysis when investigating
this problam so that it returns a vector of emptied extents rather
than std::nullopt when the extents are not scope-invariant, so that
the rank can at least be known.
Differential Revision: https://reviews.llvm.org/D123727
Items in NAMELIST groups might be host-associated implicitly-typed
variables, but name resolution can't know that when the NAMELIST
appears in a specification part and the host's execution part has
not yet been analyzed. So defer NAMELIST group item name resolution
to the end of the execution part. This is safe because nothing
else in name resolution depends on whether a variable is in a
NAMELIST group or not.
Differential Revision: https://reviews.llvm.org/D123723
Construct entities from ASSOCIATE, SELECT TYPE, and SELECT RANK
are modifiable if the are associated with modifiable variables
without vector subscripts. Update WhyNotModifiable() to accept
construct entities that are appropriate.
A need for more general error reporting from one overload of
WhyNotModifiable() caused its result type to change to
std::optional<parser::Message> instead of ::MessageFixedText,
and this change had some consequences that rippled through
call sites.
Some test results that didn't allow for modifiable construct
entities needed to be updated.
Differential Revision: https://reviews.llvm.org/D123722
TYPE IS and CLASS IS guards in SELECT TYPE constructs are
allowed to specify the same type as the type of the selector
but f18's implementation of that predicate required strict
equality of the derived type representations. We need to
allow for assumed values of LEN type parameters to match
explicit and deferred type parameter values in the selector
and require equality for KIND type parameters. Implement
DerivedTypeSpec::Match() to perform this more relaxed type
comparison, and use it in check-select-type.cpp.
Differential Revision: https://reviews.llvm.org/D123721
It is possible for generic interfaces of equivalent (but not necessarily
identical -- operator(.eq.) is equivalent to operator(==)) names to
be declared in a host scope and a nested scope, and the nested declaration
should function as an extension of the host's.
Differential Revision: https://reviews.llvm.org/D123719
Fortran allows a generic interface to have he same name as an
intrinsic procedure. If the intrinsic is explicitly marked with
the INTRINSIC attribute, restrictions apply (C848) - the generic
must contain only functions or subroutines, depending on the
intrinsic. Explicit or not, the generic overrides the intrinsic,
but the intrinsic behavior must still be available for calls
whose actual arguments do not match any of the specific procedures.
Semantics was not checking constraint C848, and it didn't allow
an explicit INTRINSIC attribute on a name of a generic interface.
Differential Revision: https://reviews.llvm.org/D123713
Shape analysis of RESHAPE(..., SHAPE=s) should of course return
the SHAPE= actual argument when it is constant; but when it is
not, its length is still known, and thus so is the rank of the
result of RESHAPE(), and shape analysis should at least return
a shape vector of the right length rather than a result that
makes the result appear to be a scalar, which can lead to some
bogus error messages.
Also, while here: rename a private GetShapeHelper::AsShape()
routine so that it can't be confused with the ones in the API
of shape.h.
Differential Revision: https://reviews.llvm.org/D123712
When a type specification appears in the prefix of a FUNCTION statement,
defer its processing as late as possible so that any symbols in the
tpe specification can be resolved in the function's scope to local
declarations, including use-associated symbols. f18 was already doing
this deferral in a limited form for derived types, and this patch
makes it work for intrinsic type parameter values as well.
In short, "real(kind(x)) function foo(x)" now works as it should.
"As late as possible" means the end of the specification part, or
the first appearance of the function result name in the specification
part.
Differential Revision: https://reviews.llvm.org/D123705
Fortran admits a few ways to have multiple symbols with the
same name in the same scope. Two of them involve generic
interfaces (from INTERFACE or GENERIC, the syntax doesn't matter);
these are allowed to inhabit a scope with either a derived type or
a subprogram that is also a specific procedure of the generic.
(But not both a derived type and a subprogram; they could not
cohabit a scope anyway, generic or not.)
In cases of USE association, f18 needs to be capable of combining
use-associated generic interfaces with other use-associated entities.
Two generics get merged (this case was nearly correct); a generic
and a derived type can merge into a GenericDetails with a shadowed
derivedType(); and a generic can replace or ignore a use-associated
procedure of the same name so long as that procedure is already
one of its specifics.
Further, these modifications to the use-associated generic
interface must be made to a local copy of the symbol. The previous
code was messing directly with the symbol in the module's scope.
The fix is basically a reimplementation of the member function
DoAddUse() in name resolution.
Differential Revision: https://reviews.llvm.org/D123704
Error messages can have a list of attachments; these are used to point
to related source locations, supply additional information, and to
encapsulate error messages that were *not* emitted in a given context
to explain why a warning was justified.
This patch adds a message severity ("Because") for that last case,
and extends to AttachTo() API to provide a means for overriding
the severity of an attached message.
Some existing message attachments had their severities adjusted,
now that we're printing them. And operator==() for Message was
cleaned up while debugging after I noticed that it was recursively
O(N**2) and subject to returning a false positive.
Differential Revision: https://reviews.llvm.org/D123710
The intrinsics DREAL, DIMAG, and DCONJG are from Fortran 77 extensions.
For DREAL, the type of argument is extended to any complex. For DIMAG
and DCONJG, the type of argument for them should be complex(8). For DIMAG,
the result type should be real(8). For DCONJG, the result type should be
complex(8). Fix the intrinsic interface for them and add test cases for
the semantic checks and the lowering.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D123459
The float number is represented as (-1)^s * 1.f * 2^(-127) for 32-bit,
where s is the signed flag, f is the mantissa. When the exponent bits
are all zeros, the float number is represented as (-1)^s * 0.f *2^(-126)
for 32-bit, in which case, the intPart is '0'.
Reviewed By: Jean Perier
https://reviews.llvm.org/D123673
During real range reduction to [0.5, 4) with
SQRT(2**(2a) * x) = SQRT(2**(2a)) * SQRT(x) = 2**a * SQRT(x)
we fall into inf. recursion if IsZero() == true.
Explicitly handle SQRT(0.0) instead of additional checks during folding. Also
add helpers for +0.0/-0.0 generation to clean up a bit.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D123131
The semantics of `-mmlir` are identical to `-mllvm`. The only notable
difference is that `-mmlir` options should be forwarded to MLIR rather
than LLVM.
Note that MLIR llvm::cl options are lazily constructed on demand (see
the definition of options in PassManagerOptions.cpp). This means that:
* MLIR global options are only visible when explicitly initialised and
displayed only when using `-mmlir --help`,
* Flang and LLVM global options are always visible and displayed when
using either `-mllvm -help` or `-mmlir --help`.
In other words, `-mmlir --help` is a superset of `-mllvm --help`. This is not
ideal, but we'd need to refactor all option definitions in Flang and
LLVM to improve this. I suggesting leaving this for later.
Differential Revision: https://reviews.llvm.org/D123297
Catch and nicely describe errors in CASE range values
that are out of range for the type of the SELECT CASE.
Differential Revision: https://reviews.llvm.org/D123708
Add a test with a range of num_images() intrinsic function
invocations, including the standard-conforming but previously
untested 'team' argument. Also test that several non-conforming
num_images() invocations generate the correct error messages.
Differential Revision: https://reviews.llvm.org/D121938
This patch supports lowering parse-tree to MLIR of ordered threads
directive following Section 2.19.9 of the OpenMP 5.1 standard.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: shraiysh
Differential Revision: https://reviews.llvm.org/D123590
This patch supports the following checks for ORDERED construct:
```
[5.1] 2.19.9 ORDERED Construct
The worksharing-loop or worksharing-loop SIMD region to which an ordered
region corresponding to an ordered construct without a depend clause
binds must have an ordered clause without the parameter specified on the
corresponding worksharing-loop or worksharing-loop SIMD directive.
The worksharing-loop region to which an ordered region that corresponds
to an ordered construct with any depend clauses binds must have an
ordered clause with the parameter specified on the corresponding
worksharing-loop directive.
An ordered construct with the depend clause specified must be closely
nested inside a worksharing-loop (or parallel worksharing-loop)
construct.
An ordered region that corresponds to an ordered construct with the simd
clause specified must be closely nested inside a simd or
worksharing-loop SIMD region.
```
Reviewed By: kiranchandramohan, shraiysh, NimishMishra
Differential Revision: https://reviews.llvm.org/D113399
Support for generating LLVM BC files is added in Flang's compiler and
frontend drivers. This requires the `BitcodeWriterPass` pass to be run
on the input LLVM IR module and is implemented as a dedicated frontend
aciton. The new functionality as seen by the user (compiler driver):
```
flang-new -c -emit-llvm file.90
```
or (frontend driver):
```
flang-new -fc1 -emit-llvm-bc file.f90
```
The new behaviour is consistent with `clang` and `clang -cc1`.
Differential Revision: https://reviews.llvm.org/D123211
Privatisation creates local copies of variables in the OpenMP region.
Two functions `createHostAssociateVarClone` and `copyHostAssociateVar`
are added to create a clone of the variable for basic privatisation and to
copy the contents for first-privatisation.
Note: Tests for more data-types will be added when the fir.do_loop is
upstreamed.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: peixin, NimishMishra
Differential Revision: https://reviews.llvm.org/D122595
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
Co-authored-by: Nimish Mishra <neelam.nimish@gmail.com>
Co-authored-by: Peixin-Qiao <qiaopeixin@huawei.com>
Handle dynamic optional argument in GET_COMMAND_ARGUMENT and GET_ENVIRONMENT_VARIABLE
(previously compiled but caused segfaults). The previous code
handled static presence/absence aspects, but not when an absent dummy optional was
passed to one of the optional intrinsic arguments.
Simplify the runtime call lowering to simply lower the runtime call without
dealing with optionality there. This keeps the optional handling logic in
IntrinsicCall.cpp.
Note that the new code will generate some extra "if (not null addr )/then/else"
when the actual arguments are always there at runtime. That makes the implementation
a lot simpler/safer, and I think it is OK for now (I do not expect these runtime
function to be called in hot loop nests).
Differential Revision: https://reviews.llvm.org/D123388
The information about OpenMP/OpenACC declarative directives in modules
should be carried in export mod files. This supports export OpenMP
Threadprivate directive and import OpenMP declarative directives.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D120396
This patch avoids to fold `fir.box_addr` when the defining `fir.embox` op
has a slice. If the op is folded the slice information are lost.
This kind of problem occurred with code like:
```
call check(y(half+1:))
```
where `y` is an array.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D123392
As Fortran 2018 3.18 states, the branch target statement can be
`forall-construct-stmt`, but cannot be `forall-stmt`. `forall-stmt` is
wrapped by `Statement` in `action-stmt` and `action-stmt` can be one
branch target statement. Fix the semantic analysis and add two
regression test cases in lowering.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D123373
This patch adds translation for allocate clause for parallel and single
constructs.
Also added tests for block constructs.
This patch also adds tests for parallel construct which were not added earlier.
Reviewed By: NimishMishra, peixin
Differential Revision: https://reviews.llvm.org/D122483
Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
The actual argument passed to STATUS may be a dummy OPTIONAL or a
disassociated POINTER/unallocated ALLOCATABLE.
Differential Revision: https://reviews.llvm.org/D123380
Reland Note: Adds a fix to properly mark a commutative operation as folded if we change the order
of its operands. This was uncovered by the fact that we no longer re-process constants.
This avoids accidentally reversing the order of constants during successive
application, e.g. when running the canonicalizer. This helps reduce the number
of iterations, and also avoids unnecessary changes to input IR.
Fixes#51892
Differential Revision: https://reviews.llvm.org/D122692
This patch enhances the CSE pass to deal with simple cases of duplicated
operations with MemoryEffects.
It allows the CSE pass to remove safely duplicate operations with the
MemoryEffects::Read that have no other side-effecting operations in
between. Other MemoryEffects::Read operation are allowed.
The use case is pretty simple so far so we can build on top of it to add
more features.
This patch is also meant to avoid a dedicated CSE pass in FIR and was
brought together afetr discussion on https://reviews.llvm.org/D112711.
It does not currently cover the full range of use cases described in
https://reviews.llvm.org/D112711 but the idea is to gradually enhance
the MLIR CSE pass to handle common use cases that can be used by
other dialects.
This patch takes advantage of the new CSE capabilities in Fir.
Reviewed By: mehdi_amini, rriddle, schweitz
Differential Revision: https://reviews.llvm.org/D122801
Fix https://github.com/flang-compiler/f18-llvm-project/issues/1416.
The `constRows` variable was being decremented too soon, causing the
last constant interior dimension extent being used to multiply the GEP
offset. This lead to wrong address computation and caused segfaults.
Note: also upstream fir.embox tests that can be upstreamed.
Differential Revision: https://reviews.llvm.org/D123130
Do not use the shift of a fir.embox to set lower bounds if there is
a fir.slice operand. This matches Fortran semantics where lower bounds
of array sections are ones.
Note that in case there is a fir.slice, the array shift may be provided
because it is used to calculate the origin/base address of an array slice.
Add a TODO for substring codegen since I noticed it was not upstreamed
yet and would cause some program to silently compile incorrectly.
Differential Revision: https://reviews.llvm.org/D123123
Any header or module file in the Flang source directory is of no use to
the compiler unless it is copied into the build directory. Indeed, all
compiler search paths are relative to the compiler executable (flang-new
in our case). Hence, "omp_lib.h" should be copied into the build
directory alongside other compiler-provided files that can be "included"
(header files) or "used" (module files).
For now, "omp_lib.h" is copied into "<build-dir>/include/flang/OpenMP".
We may decide to change this in future. For example, Clang copies a
bunch of runtime headers into “<build-dir>/lib/clang/<version-number>”.
We could also consider using a similar header from a different
sub-project.
Flang's driver search path is updated accordingly. A rule for
"installing" the "omp_lib.h" header is _yet to be added_ (we will also
need to determine the suitable location for this).
Differential Revision: https://reviews.llvm.org/D122015
The actual argument shall have deferred the same type parameters as
the dummy argument if the argument is allocatable or pointer variable.
Currently programs not following this get one crash during execution.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D122779
This patch adds tests for the array-value-copy pass with array assignment
involving Fortran pointers.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D122878
Peixin Qiao