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
If a programmer is able to compile and link a program that contains types that
are not yet supported by the runtime, it must be because they're not yet
implemented.
This change will make it easier to find unimplemented code in tests.
Differential Revision: https://reviews.llvm.org/D125046
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
All frontend actions that generate code (MLIR, LLVM IR/BC,
Assembly/Object Code) are re-factored as essentially one action,
`CodeGenAction`, with minor specialisations. To facilate all this,
`CodeGenAction` is extended to hold `TargetMachine` and backend action
type (MLIR vs LLVM IR vs LLVM BC vs Assembly vs Object Code).
`CodeGenAction` is no longer a pure abstract class and the
corresponding `ExecuteAction` is implemented so that it covers all use
cases. All this allows a much better code re-use.
Key functionality is extracted into some helpful hooks:
* `SetUpTargetMachine`
* `GetOutputStream`
* `EmitObjectCodeHelper`
* `EmitBCHelper`
I hope that this clarifies the overall structure. I suspect that we may
need to revisit this again as the functionality grows in complexity.
Differential Revision: https://reviews.llvm.org/D124665
Flang transformational runtime was previously reporting conformity
issues in a zero based fashion to describe which dimension is non
conformant. This may confuse Fortran user, especially when the message
is about a dimension other than the first one.
Differential Revision: https://reviews.llvm.org/D124941
*SUMMARY*
Currently, the frontend driver assumes that a target triple is either:
* provided by the frontend itself (e.g. when lowering and generating
code),
* specified through the `-triple/-target` command line flags.
If `-triple/-target` is not used, the frontend will simply use the host
triple.
This is going to be insufficient when e.g. consuming an LLVM IR file
that has no triple specified (reading LLVM files is WIP, see D124667).
We shouldn't require the triple to be specified via the command line in
such situation. Instead, the frontend driver should contain a good
default, e.g. the host triple.
This patch updates Flang's `CompilerInvocation` to do just that, i.e.
defines its default target triple. Similarly to Clang:
* the default `CompilerInvocation` triple is set as the host triple,
* the value specified with `-triple` takes precedence over the frontend
driver default and the current module triple,
* the frontend driver default takes precedence over the module triple.
*TESTS*
This change requires 2 unit tests to be updated. That's because relevant
frontend actions are updated to assume that there's always a valid
triple available in the current `CompilerInvocation`. This update is
required because the unit tests bypass the regular `CompilerInvocation`
set-up (in particular, they don't call
`CompilerInvocation::CreateFromArgs`). I've also taken the liberty to
disable the pre-precossor formatting in the affected unit tests as well
(it is not required).
No new tests are added. As `flang-new -fc1` does not support consuming
LLVM IR files just yet, it is not possible to compile an LLVM IR file
without a triple. More specifically, atm all LLVM IR files are generated
and stored internally and the driver makes sure that these contain a
valid target triple. This is about to change in D124667 (which adds
support for reading LLVM IR/BC files) and that's where tests for
exercising the default frontend driver triple will be added.
*WHAT DOES CLANG DO?*
For reference, the default target triple for Clang's
`CompilerInvocation` is set through option marshalling infra [1] in
Options.td. Please check the definition of the `-triple` flag:
```
def triple : Separate<["-"], "triple">,
HelpText<"Specify target triple (e.g. i686-apple-darwin9)">,
MarshallingInfoString<TargetOpts<"Triple">, "llvm::Triple::normalize(llvm::sys::getDefaultTargetTriple())">,
AlwaysEmit, Normalizer<"normalizeTriple">;
```
Ideally, we should re-use the marshalling infra in Flang.
[1] https://clang.llvm.org/docs/InternalsManual.html#option-marshalling-infrastructure
Differential Revision: https://reviews.llvm.org/D124664
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
MLIR has a common pattern for "arguments" that uses syntax
like `%x : i32 {attrs} loc("sourceloc")` which is implemented
in adhoc ways throughout the codebase. The approach this uses
is verbose (because it is implemented with parallel arrays) and
inconsistent (e.g. lots of things drop source location info).
Solve this by introducing OpAsmParser::Argument and make addRegion
(which sets up BlockArguments for the region) take it. Convert the
world to propagating this down. This means that we correctly
capture and propagate source location information in a lot more
cases (e.g. see the affine.for testcase example), and it also
simplifies much code.
Differential Revision: https://reviews.llvm.org/D124649
Notes from the Flang Biweekly Sync calls have been merged into the same document as the notes from the Flang Technical calls. This patch updates the link in the GettingInvolved document to point to the new location.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D124689
A recent change is eliciting a valid warning from the out-of-tree
flang build bot; fix by using a reference in a range-based for().
Differential Revision: https://reviews.llvm.org/D124682
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 is a common extension, though semantics differ across
compilers. I've chosen to interpret the CHARACTER data
as if it were an arbitrary-precision integer value and
format or read it as such. This matches Intel's compilers
and nvfortran. (GNU Fortran can't handle lengths > 1 and XLF
seems to get the enddianness wrong.)
This patch generalizes the previous implementations of
B/O/Z input and output so that they'll work for arbitrary data
in memory, and then uses them for all B/O/Z input/output,
including (now) CHARACTER.
Differential Revision: https://reviews.llvm.org/D124547
The asm parser had a notional distinction between parsing an
operand (like "%foo" or "%4#3") and parsing a region argument
(which isn't supposed to allow a result number like #3).
Unfortunately the implementation has two problems:
1) It didn't actually check for the result number and reject
it. parseRegionArgument and parseOperand were identical.
2) It had a lot of machinery built up around it that paralleled
operand parsing. This also was functionally identical, but
also had some subtle differences (e.g. the parseOptional
stuff had a different result type).
I thought about just removing all of this, but decided that the
missing error checking was important, so I reimplemented it with
a `allowResultNumber` flag on parseOperand. This keeps the
codepaths unified and adds the missing error checks.
Differential Revision: https://reviews.llvm.org/D124470
When the last operation on a foramtted sequential or stream file (prior
to an implied or explicit ENDFILE) is a non-advancing WRITE, ensure
that any partial record data is emitted to the file without a line
terminator. Further, when that last record is read with a non-advancing
READ, ensure that it won't raise an end-of-record condition after its
data, but instead will signal an end-of-file.
Differential Revision: https://reviews.llvm.org/D124546
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
When passing a scalar .FALSE. as the MASK argument to MAXLOC, we were getting
bad memory references. We were falling into the code intended when the MASK
argument was missing.
I fixed this by checking for a scalar MASK with a .FALSE. value and
setting the result to all zeroes in that case. I also added tests for
MAXLOC and MINLOC with scalar values of .TRUE. and .FALSE. for the MASK
argument.
I also special cased situations where the MASK argument is a scalar with
a .TRUE. value and passed along a nullptr in such cases.
Along the way, I eliminated the unused "chars" argument from the constructor
for ExtremumLocAccumulator.
Differential Revision: https://reviews.llvm.org/D124484
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
Name resolution fails with a bogus "is not a variable" error message
when a host-associated object appears in a NAMELIST group. The root
cause is that ConvertToObjectEntity() returns false for host-associated
objects. Fix that, and also apply a similar fix to ConvertToProcEntity()
nearby.
Differential Revision: https://reviews.llvm.org/D124541
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>
This patch basically implements [1] in ExecuteCompilerInvocation.cpp. It
also:
* replaces `CreateFrontendBaseAction` with `CreateFrontendAction`
(only one method is needed ATM, this change removes the extra
indirection)
* removes `InvalidAction` from the `ActionKind` enum (I don't think it
adds much and keeping it would mean adding a new void case in
`CreateFrontendAction`)
* sets the default frontend action in FrontendOptions.h to
`ParseSyntaxOnly` (note that this is still overridden independently
in `ParseFrontendArg` in CompilerInvocation.cpp)
No new functionality is added, hence no tests.
[1] https://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations
Differential Revision: https://reviews.llvm.org/D124245
Semantics now needs to preserve the parse trees from module files,
in case they contain parameterized derived type definitions with
component initializers that may require re-analysis during PDT
instantiation. Save them in the SemanticsContext.
Differential Revision: https://reviews.llvm.org/D124467
A recent change assumed that the native C++ "long double" maps to
a Fortran data type; but this turns out to not be true for ppc64le,
which uses "double-double" for "long double".
This is a quick patch to get the ppc64le flang build bot back up.
A better fix that either uses HostTypeExists<> or replaces "long double"
with "ieee128_t" (or some other solution) is expected to follow soon.
Differential Revision: https://reviews.llvm.org/D124423
A template argument was hard-coded as the Integer type category
rather than properly forwarding the type category of the data for
type-specific instantiations of total (no DIM=) MAXLOC and MINLOC.
This broke total MAXLOC and MINLOC reductions for real and character
data.
Differential Revision: https://reviews.llvm.org/D124303
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
F(X)=Y may be initially parsed as a statement function definition; an
existing pass will detect statement functions that should be rewritten
into assignment statemets with array element references as their
left-hand side variables. However, F() may also be a reference to a
function that returns a data pointer, and f18 did not handle this
case correctly.
The right fix is to rewrite the parse tree for F(X)=Y into an assignment
to a function reference result. The cases that are actually assignments
to array elements -- including all of the cases previously handled --
will have their left-hand sides converted to array element references
later by another existing rewriting step.
Differential Revision: https://reviews.llvm.org/D124299
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
Now that dialect constructors are generated in the .cpp file, we can
drop all of the dependent dialect includes from the .h file.
Differential Revision: https://reviews.llvm.org/D124298
When PAD='NO' and ADVANCE='YES', we currently signal an input
error when a formatted read tries to go past the end of a record
only when a fixed RECL= is in effect. Other compilers will signal
an error without RECL= too, and that seems like a precedent we
should follow.
Differential Revision: https://reviews.llvm.org/D124301
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.
Differential Revision: https://reviews.llvm.org/D124300
Blanks are allowed in more places than I allowed for, and
"NAN(foobar)" is allowed to have any parenthesis-balanced
characters in parentheses.
Update: Fix up old sanity test, then avoid usage of "limit" when null.
Differential Revision: https://reviews.llvm.org/D124294
When editing numeric input, always skip leading spaces, even if
BZ mode (or BLANK='ZERO') is in effect; otherwise, a sign character
preceded by blanks will not be recognized.
Differential Revision: https://reviews.llvm.org/D124278
A recent change that corrected the name resolution of a generic interface
when the same name was visible in scope incorrectly prevented a local
generic from shadowing an outer name that is not a generic, subprogram,
or derived type -- e.g., a simple variable -- leading to an inappropriate
error message.
Differential Revision: https://reviews.llvm.org/D124276
This patch adds a few new member methods in the `PluginParseTreeAction`
frontend action base class. With these new methods, the plugin API
becomes independent of the driver internals. In particular, plugin
writers no longer require the `CompilerInstance.h` header file to access
various driver data structures (instead, they can use newly added
hooks).
This change is desirable as `CompilerInstance.h` includes various
headers from Clang (both explicitly and implicitly). Some of these
header files are generated at build time (through TableGen) and
including them creates a dependency on some of Clang's build targets.
However, plugins in Flang should not depend on Clang build targets.
Note that plugins might still work fine most of the time, even without
this change and without adding Clang build targets as dependency in
plugin's CMake definition. Indeed, these Clang build targets are often
generated early in the build process. However, that's not guaranteed and
we did notice that on occasions plugins would fail to build.
Differential Revision: https://reviews.llvm.org/D120999
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
When resolving a procedure reference, do not allow a successful
intrinsic procedure probe result to override an existing
symbol.
Differential Revision: https://reviews.llvm.org/D123905
Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.
This change is enabled only for GCC builds with GCC >= 9;
an earlier attempt (D122441) ran into bugs in some versions of
clang and was reverted rather than simply disabled; and it is
not well tested with MSVC. In non-GCC and older GCC builds,
common::visit() is simply an alias for std::visit().
When an error occurs in a formatted sequential output statement
and no output was ever emitted, don't emit a blank record.
This matches the error case behavior of other Fortran compilers.
Differential Revision: https://reviews.llvm.org/D123734
The x%KIND inquiry needs to be supported when 'x' is itself
a complex part reference or a type parameter inquiry.
Differential Revision: https://reviews.llvm.org/D123733
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
A predicate expression made ENDFILE statements significant
only for sequential files, but it's applicable to formatted
stream output as well.
Differential Revision: https://reviews.llvm.org/D123730
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
Prior to this patch, the semantics utility GetExpr() will crash
unconditionally if it encounters a typed expression in the parse
tree that has not been set by expression semantics. This is the
right behavior when called from lowering, by which time it is known
that the program had no fatal user errors, since it signifies a
fatal internal error. However, prior to lowering, in the statement
semantics checking code, a more nuanced test should be used before
crashing -- specifically, we should not crash in the face of a
missing typed expression when in error recovery mode.
Getting this right requires GetExpr() and its helper class to have
access to the semantics context, so that it can check AnyFatalErrors()
before crashing. So this patch touches nearly all of its call sites.
Differential Revision: https://reviews.llvm.org/D123873
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
When formatted input (not list-directed or NAMELIST) is in "BZ" mode,
either because a BZ control edit descriptor appeared in a FORMAT or
BLANK="ZERO" appeared in OPEN or READ, input editing must not skip
over blanks before or within the input field.
Differential Revision: https://reviews.llvm.org/D123725
To avoid clashing with names of user derived types, the redundant
syntax TYPE(intrinsic type spec) must be interpreted as a monomorphic
derived type when "intrinsic type spec" is a single word. This
affects TYPE(BYTE) and TYPE(DOUBLECOMPLEX), but not TYPE(DOUBLE COMPLEX)
in free form source.
Differential Revision: https://reviews.llvm.org/D123724
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
A generic interface (however spelled) can have the same name as
an intrinsic procedure in the same scope. When an explicit INTRINSIC
attribute statement appears in a nested scope, semantics was
unconditionally declaring a new symbol that hid the generic entirely.
Catch this case and create instead a host association symbol for
the generic that can then be decorated with the INTRINSIC attribute.
Differential Revision: https://reviews.llvm.org/D123718
When formatted non-advancing output ends in a control edit descriptor
like nX or Tn or TRn that effectively extends the record, fill any
gap with explicit blanks at the completion of the WRITE.
Differential Revision: https://reviews.llvm.org/D123716
Formatted READs of REAL should convert the exception flags from
the decimal-to-binary conversion library into real runtime FP
exceptions so that they at least show up in the termination message
of a STOP statement.
Differential Revision: https://reviews.llvm.org/D123714
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
A recent change to implement UTF-8 encoding should have
made the encoding conditional only for CHARACTER(KIND=1)
to enable UTF-8 output vs. Latin-1 or whatever. UTF-8 output
of wider CHARACTER kinds should not be conditional (until we choose
to support UCS-16, maybe). So wider CHARACTER kinds are being
emitted with extra zero bytes; this patch fixes them.
Differential Revision: https://reviews.llvm.org/D123711
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
https://reviews.llvm.org/D123211 broke builds that set both
`LLVM_BUILD_LLVM_DYLIB` and `LLVM_LINK_LLVM_DYLIB` (see [1]). This patch
fixes that.
The build failure was caused by the fact that the LLVMPasses library,
which is an LLVM "component", was listed directly as link-time
dependency. Instead, one should use `LINK_COMPONENTS` in CMake files. I
made an identical mistake recently and then subsequently fixed it in
https://reviews.llvm.org/D121461 - please visit that revision for more
detail.
I'm merging this without a review. The change is straightforward, we
recently discussed it and I was able to confirm locally that it fixes
the build issue.
[1] https://lab.llvm.org/buildbot/#/builders/177/builds/4619
Correct the implementation of non-advancing I/O after some testing
to ensure that T tab edit descriptors are not allowed to back up
into positions of a record prior to where it stood at the beginning
of the I/O statement.
Differential Revision: https://reviews.llvm.org/D123709
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
When padding is required in a COMMON block to ensure alignment
of a component, emit a portability warning.
Differential Revision: https://reviews.llvm.org/D123706
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
Most Fortran compilers appear to return the process time
for calls to CPU_TIME, where the flang implementation
prior to this change was returning the time used by the
current thread. This would cause incorrect time being
reported when for example OpenMP is used to share work
across multiple CPUs.
This patch changes the order so the selection of "what
time to return" so that if there is a process time to
report, that is the reported value, and only if that is
not available, the thread time is considerd instead.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D123416
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
isAbsent/isPresent helpers only give information about static presence
of intrinsic arguments. Many intrinsic arguments optionality is dynamic
(an absent dummy can legally be passed to these intrinsics). This
requires a different handling (like `handleDynamicOptional`).
Rename the helpers to avoid misleading coder/reader into thinking all
optionality cases are covered by them.
Differential Revision: https://reviews.llvm.org/D123378
This patch revamps the BranchOpInterface a bit and allows a proper implementation of what was previously `getMutableSuccessorOperands` for operations, which internally produce arguments to some of the block arguments. A motivating example for this would be an invoke op with a error handling path:
```
invoke %function(%0)
label ^success ^error(%1 : i32)
^error(%e: !error, %arg0 : i32):
...
```
The advantages of this are that any users of `BranchOpInterface` can still argue over remaining block argument operands (such as `%1` in the example above), as well as make use of the modifying capabilities to add more operands, erase an operand etc.
The way this patch implements that functionality is via a new class called `SuccessorOperands`, which is now returned by `getSuccessorOperands`. It basically contains an `unsigned` denoting how many operator produced operands exist, as well as a `MutableOperandRange`, which are the usual forwarded operands we are used to. The produced operands are assumed to the first few block arguments, followed by the forwarded operands afterwards. The role of `SuccessorOperands` is to provide various utility functions to modify and query the successor arguments from a `BranchOpInterface`.
Differential Revision: https://reviews.llvm.org/D123062
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
Unit numbers must fit on a default integer. It is however possible that
the user provides the unit number in UNIT with a wider integer type.
In such case, lowering was previously silently narrowing
the value and passing the result to the BeginXXX runtime entry points.
Cases where the conversion caused overflow were not reported/caught.
Most existing compilers catch these errors and raise an IO error.
Add a CheckUnitNumberInRange runtime API to do the same in f18.
This runtime API has its own error management interface (i.e., does not
use GetIoMsg, EndIo, and EnableHandlers) because the usual error
management requires BeginXXX to be called to set up the error
management. But in this case, the BeginXXX cannot be called since
the bad unit number that would be provided to it overflew (and in the worst
case scenario, the narrowed value could point to a different valid unit
already in use). Hence I decided to make an API that must be called
before the BeginXXX and should trigger the whole BeginXXX/.../EndIoStatement
to be skipped in case the unit number is too big and the user enabled
error recovery.
Note that CheckUnitNumberInRange accepts negative numbers (as long as
they can fit on a default integer), because unit numbers may be negative
if they were created by NEWUNIT.
Differential Revision: https://reviews.llvm.org/D123157
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
This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implicit" fallback path to use the name of the type, instead of using
a static template variable (which breaks shared libraries). The major downside to this
is that it adds some additional initialization costs for the implicit path. Given the
use of type names for uniqueness in the fallback, we also no longer allow types
defined in anonymous namespaces to have an implicit TypeID. To simplify defining
an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro
was added to allow for explicitly defining a TypeID directly on an internal class.
To help identify when types are using the fallback, `-debug-only=typeid` can be
used to log which types are using implicit ids.
This change generally only requires changes to the test passes, which are all defined
in anonymous namespaces, and thus can't use the fallback any longer.
Differential Revision: https://reviews.llvm.org/D122775
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
These are mostly small changes to make the code a bit clearer and more
consistent. Summary of changes:
* add missing namespace qualifiers (that's the preference in Flang)
* replace const member methods with static methods (to avoid passing
the *this pointer unnecessarily)
* rename `currentObjTy` (current object type) as `cpnTy` (component
type) - the latter feels more fitting
* remove redundant `return failure();` calls (` return
mlir::emitError` gives the same result)
* updated a few comments
Differential Revision: https://reviews.llvm.org/D122799
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
In case a character component PDT length only depends on kind parameters,
fold it while instantiating the PDT. This is especially important if the
component has an initializer because later semantic phases (offset
computation or runtime type info generation) might get confused and
generate offset/type info that will lead to crashes in lowering.
Differential Revision: https://reviews.llvm.org/D122938
This patch adds FIR to LLVM test for fir.address_of.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D122889
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds some test for the `fir.array_modify` operation
in the array-value-copy pass
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D122809
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds some test cases for the array-value-copy pass with slices.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D122807
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds tests for the `fir.is_present`
translation.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D122813
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch addes some global initialization and global
box initialization tests.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D122881
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Add tests for fir.select_rank and
fir.select_case.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D122888
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Previously, some semantic checks that are checking if an entity is an
allocatable were relying on the expression being a designator whose
last symbol has the allocatable attribute.
This is wrong since this was considering substrings and array sections of
allocatables as being allocatable. This is wrong (see NOTE 2 in
Fortran 2018 section 9.5.3.1).
Add evaluate::IsAllocatableDesignator to correctly test this.
Also add some semantic tests for ALLOCATED to test the newly added helper.
Note that ifort and nag are rejecting coindexed-named-object in
ALLOCATED (`allocated(coarray_scalar_alloc[2])`).
I think it is wrong given allocated argument is intent(in) as per
16.2.1 point 3.
So 15.5.2.6 point 4 regarding allocatable dummy is not violated (If the actual
argument is a coindexed object, the dummy argument shall have the INTENT (IN)
attribute.) and I think this is valid. gfortran accepts it.
The need for this helper was exposed in https://reviews.llvm.org/D122779.
Differential Revision: https://reviews.llvm.org/D122899
Co-authored-by: Peixin-Qiao <qiaopeixin@huawei.com>
This reverts commit 59bbc7a085.
This exposes an issue breaking the contract of
`applyPatternsAndFoldGreedily` where we "converge" without applying
remaining patterns.
Re-introduce a fully qualified type on teh fir.freemem operation.
Since this is the only operation where the prefix gets elided in fir, this
patch make it fully qualified so the dialect syntax feels more consistent.
Reviewed By: vdonaldson
Differential Revision: https://reviews.llvm.org/D122839
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
Runtime was crashing when an INTEGER passed in formatted output with
a bad edit descriptor even when the user did provide IOSTAT. Flang
is already signaling an error when facing similar error with other
types. Do the same with INTEGERs.
The input case is already signaling an error in the related input error
case.
Differential Revision: https://reviews.llvm.org/D122749
When including debug lines as code, the `D` should be considered as
a white space. Currently an error was raised about bad labels because
it the `D` remained a `D` when considering the source line as code.
Differential Revision: https://reviews.llvm.org/D122711
Statically checking for overflow with
if constexpr (sizeof(std::size_t) <= sizeof(std::int64_t)) {
return static_cast<std::int64_t>(length);
}
Doesn't work if `sizeof(std::size_t) == sizeof(std::int64_t)` because std::size_t
is unsigned.
if `length == std::numeric_limits<size_t>` casting it to `int64_t` is going to overflow.
This code would be much simpler if returning a `uint64_t` instead of a signed
value...
Differential Revision: https://reviews.llvm.org/D122705
When folding MAXLOC/MINLOC, the current element being compared was moved twice
in row in case it became the new extremum. With numeric and logical types, it
made no difference (std::move is a no-op for them), but for characters
where the string storage is actually moved, it caused the new extremum to
be set to the empty string, leading to wrong results.
Note: I could have left the first std::move relating to logical Findloc, but it
brings nothing and makes the code less auditable, so I also removed it.
Differential Revision: https://reviews.llvm.org/D122590
This patch adds translation for parallel sections from PFT to MLIR.
Reviewed By: kiranchandramohan, NimishMishra
Differential Revision: https://reviews.llvm.org/D122464
This patch makes -version valid, and --version invalid, for
flang-new -fc1. The invocation
flang-new --version
remains valid. This behaviour is consistent with clang
(and with clang -cc1 and clang -cc1as).
Previously, flang-new -fc1 accepted --version (as per Options.td), but
the frontend driver acutally checks for -version. As a result,
flang-new -fc1 --version
triggered no action, emitted no message, and stalled waiting for
standard input.
Fixes#51438
Reviewed By: PeteSteinfeld, awarzynski
Differential Revision: https://reviews.llvm.org/D122542
Implement constant folding for the intrinsic function NEAREST()
and the related functions IEEE_NEXT_AFTER(), IEEE_NEXT_UP(), and
IEEE_NEXT_DOWN().
Differential Revision: https://reviews.llvm.org/D122510
- Adds default implementations of `isDefinedOutsideOfLoop` and `moveOutOfLoop` since 99% of all implementations of these functions were identical
- `moveOutOfLoop` takes one operation and doesn't return anything anymore. 100% of all implementations of this function would always return `success` and uses would either respond with a pass failure or an `llvm_unreachable`.
Enable lowering to the relaxed and precise variants in the pgmath
library.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D122484
This patch adds the lowering of coarray statements to the runtime
functions. The runtime functions are currently not implemented.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D122466
This patch adds the ReductionClauseInterface and also adds reduction
support for `omp.parallel` operation.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D122402
PointerDeallocate was silently doing nothing because it relied on
Destroy that doe not do anything for Pointers. Add an option to Destroy
in order to destroy pointers.
Add a unit test for PointerDeallocate.
Differential Revision: https://reviews.llvm.org/D122492
STATUS='NEW' and 'REPLACE' require FILE= to be present.
STATUS='SCRATCH' may not appear with FILE=.
These errors are caught at compilation time when constant character
strings are used in an OPEN statement, but the runtime needs
to enforce them as well to catch errors in OPEN statements
with character variables and expressions.
Differential Revision: https://reviews.llvm.org/D122509
The interfaces to C_ASSOCIATED()'s specific procedures must be
PURE so that they are accepted for use in specification expressions.
Differential Revision: https://reviews.llvm.org/D122438
Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.
Differential Revision: https://reviews.llvm.org/D122441
Assignment semantics was coughing up bad errors and crashes for
intrinsic assignments to unlimited polymorphic entities while
looking for any (impossible) user defined ASSIGNMENT(=) generic
or intrinsic type conversion.
Differential Revision: https://reviews.llvm.org/D122440
Follow up of https://reviews.llvm.org/D121488. Ensure lower bounds
are `1` when the related dimension extent is zero. Note that lower
bounds from descriptors are now guaranteed to fulfill this property
after the runtime/codegen patches.
Also fixes explicit shape array extent lowering when instantiating
variables to deal with negative extent cases (issue found while testing
LBOUND edge case). This notably caused allocation crashes when dealing
with automatic arrays with reversed bounds or negative size
specification expression. The standard specifies that the extent of such
arrays is zero. This change has some ripple effect in the current lit
tests.
Add move two helpers as part of this change:
- Add a helper to tell if a fir::ExtendedValue describes an assumed size
array (last dimension extent is unknown to the compiler, both at compile
time and runtime).
- Move and share getIntIfConstant from Character.cpp so that it can be
used elsewhere (NFC).
Differential Revision: https://reviews.llvm.org/D122467
The "seenProcs" sets passed as arguments to the procedure and dummy
procedure characterization routines need to be passed by value so that
local updates to those sets do not become permanent. They are
presently passed by reference and that has led to bogus errors about
recursively defined procedures in testing.
(It might be faster to pass the sets by reference and undo those local
updates in these functions, but that's error-prone, and the performance
difference is not expected to be detectable in practice.)
Differential Revision: https://reviews.llvm.org/D122439
The intrinsic returns the character located at the position requested
in the ASCII sequence. The intrinsic is lowered to inline FIR code.
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: clementval
Differential Revision: https://reviews.llvm.org/D122480
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Follow-up of https://reviews.llvm.org/D121488 to ensure all descriptors
created inline complies with LBOUND requirement that the lower bound is
`1` when the related dimension extent is zero.
Both fir.xrebox and fir.xembox codegen is updated to enforce this
constraint.
Also upstream the "normalized lower bound" attribute that was added in fir-dev
since embox codegen was upstreamed, it is conflicting with this patch
otherwise.
Differential Revision: https://reviews.llvm.org/D122419
GetLowerBoundHelper rewrite in https://reviews.llvm.org/D121488 was
incorrect with POINTER/ALLOCATABLE components. The rewrite created a
descriptor inquiry to the component symbol only instead of the whole
named entity. The base information was lost, and not retrievable.
LBOUND(a(10)%p) became LBOUND(p).
Fix this regression, and also update DescriptorInquiry unparsing to
carry the kind information. DescriptorInquiries are KIND 8 expressions,
while LBOUND/SIZE/RANK, %LEN are default kind expressions.
This caused `print *,lbound(x,kind=8)` to unparse as `print*,lbound(x)` which is not
semantically the same (this unparsing issue was not an issue for
lowering, but I noticed it while writing my regression test).
Differential Revision: https://reviews.llvm.org/D122406
This patch adds the lowering for the `mvbits`
intrinsic.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122412
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
To make it easier to find things that are not yet implemented, I'm changing the
messages that appear in the compiler's output to all have the string "not yet
implemented:".
These changes apply to files in the front end. I have another set of changes
to files in the lowering code.
Differential Revision: https://reviews.llvm.org/D122355
This patch adds lowering for the `!$acc wait` directive
from the PFT to OpenACC dialect.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122399
This patch adds lowering for the `!$acc data`
from the PFT to OpenACC dialect.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D122384
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122398
This patch adds lowering for the `!$acc update`
from the PFT to OpenACC dialect.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D122387
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122396
This patch adds lowering for the `!$acc init` and `!$acc shutdown`
from the PFT to OpenACC dialect.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D122384
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122387
This patch adds lowering for the `!$acc exit data` directive
from the PFT to OpenACC dialect.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D122384
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122386
This patch adds lowering for the `!$acc enter data` directive
from the PFT to OpenACC dialect.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122384
This patches adds lowering tests for some array
expressions use cases.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122380
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
There is no need to lower the implicit lower bounds for assumed-shape
array in lowerExplicitLowerBounds. Remove the unused code.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D122280
Similarly to LBOUND in https://reviews.llvm.org/D121488, UBOUND must
return zero for an empty dimension, no matter the specification
expression.
Add a GetUBOUND method to be used in expression rewrite that prevents
folding UBOUND to a bound specification expression if the extent is
not a compile time constant.
Fold the case where the extents is known to be zero (and also deal with
this case in LBOUND since we can and should to comply with constant
expression requirements).
Differential Revision: https://reviews.llvm.org/D122242
This patch adds lowering support (from PFT to FIR) for sections construct
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D122302
This patch adds translation for single construct along with nowait
clause from PFT to FIR.
Allocate clause is added as a TODO as handleAllocateClause is added in
D122302.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D122324
This patch rearranges the generator functions for various intrinsics.
The rearrangement will help to identify any missing functionality.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122334
Add test for forall lowering use case.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122356
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds more lowering tests from the PFT to FIR.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122354
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds lowering tests for Fortran
interfaces.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122326
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Add more use cases of lowering of derived types.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122329
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This patch adds test for the lowering of Fortran modules.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122317
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
this patch adds lowering tests for
netsed where statements
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122323
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds some lowering tests for globals.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122322
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds lowering tests for IO related use cases.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122321
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds a lowering test for the namelist.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122318
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
The intrinsic computes the sin, cosine values. By default they are lowered
to runtime calls to the pgmath library, for llvm lowering they are
lowered to llvm intrinsics. The generic and llvm lowering does not
lower floating point types with kind greater than 8, the llvm lowering
does not support the complex types.
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: clementval
Differential Revision: https://reviews.llvm.org/D122320
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
The intrinsic computes the tan and hyperbolic sin, cosine values. By
default they are lowered to runtime calls to the math library. Not all
types are supported currently. The generic and llvm lowering does not
lower floating point types with kind greater than 8, the llvm lowering
does not support the complex types.
Note: tanh is not present in fir-dev hence ignoring for now. We can add
support after upstreaming is complete. sin and cos will come in separate
patches since they have llvm intrinsic lowering.
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: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122264
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: William Moses <gh@wsmoses.com>
This patch some lowering tests for characters related operations.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122310
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 patch adds various lowering test
for calls.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122306
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Mats Petersson <mats.petersson@arm.com>
This patch adds some lowering tests.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122308
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds a lowering test for the C
interoperability.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122307
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds tests for flush and master constructs
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
Differential Revision: https://reviews.llvm.org/D122250
Co-authored By: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
This patch
- adds assembly format for `omp.wsloop` operation
- removes the `parseClauses` clauses as it is not required anymore
This is expected to be the final patch in a series of patches for replacing
parsers for clauses with `oilist`.
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D121367
This patch adds some lowering tests for the `forall` construct.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122253
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds test for calls with POINTER dummy arguments on the caller side.
It also fixes some formatting error that was introduced when upstreaming
the other pointer tests.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122238
Co-authored-by: Jean Perier <jperier@nvidia.com>
Implements UTF-8 encoding and decoding for external units
with OPEN(ENCODING='UTF-8'). This encoding applies to default
CHARACTER values that are not 7-bit ASCII as well as to
the wide CHARACTER kinds 2 and 4. Basic testing is in place
via direct calls to the runtime I/O APIs, but serious checkout
awaits lowering support of the wide CHARACTER kinds.
Differential Revision: https://reviews.llvm.org/D122038
Name resolution was crashing while processing the ENTRY statement
due to a lack of special-case code necessary to handle the indirection
needed when the generic has the same name as the ENTRY.
Differential Revision: https://reviews.llvm.org/D122050
The intrinsic computes the square root for real and complex numbers. By
default they are lowered to runtime calls to libpgmath. With the llvm
option, it can be lowered to llvm intrinsics (not all types .eg. complex
are supported for llvm lowering).
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: schweitz
Differential Revision: https://reviews.llvm.org/D122018
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
In FIR, we want to wrap function pointers in a special box known as a
boxproc value. Fortran has a limited form of dynamic scoping
[https://tinyurl.com/2p8v2hw7] between "host procedures" and "internal
procedures". There are a number of implementations possible.
Boxproc typed values abstract away the implementation details of when a
function pointer can be passed directly (as a raw address) and when a
function pointer has to account for the presence of a dynamic scope.
When lowering Fortran syntax to FIR, all function pointers are emboxed
as boxproc values.
When creating LLVM IR, we must strip away the abstraction and produce
low-level LLVM "assembly" code. This patch implements that
transformation as converting the boxproc values to either raw function
pointers or executable trampolines on the stack as needed. The
trampoline then captures the dynamic scope context within an executable
thunk that can be passed instead of the function's raw address.
Some extra handling is required for Fortran functions that return a
character value to deal with LEN values here.
Some of the code in Bridge.cpp and ConvertExpr.cpp and be re-arranged to
faciliate the upstreaming effort.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122223
Co-authored-by: mleair <leairmark@gmail.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>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
The intrinsic computes the exponent, log real and complex numbers and
log10 for real numbers. By default they are lowered to runtime calls to
libpgmath. kind=10 and 16 are not supported. With the llvm option, it
can be lowered to llvm intrinsics (not all types .eg. complex are
supported for llvm lowering).
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: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122132
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: William S Moses <gh@wsmoses.com>
This patch adds translation from PFT to FIR for critical construct.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Co-authored-by: kiranchandramohan <kiranchandramohan@gmail.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D122218
I am not sure about the meaning of Type in the name (was it meant be interpreted as Kind?), and given the importance and meaning of Type in the context of MLIR, its probably better to rename it. Given the comment in the source code, the suggestion in the GitHub issue and the final discussions in the review, this patch renames the OperandType to UnresolvedOperand.
Fixes https://github.com/llvm/llvm-project/issues/54446
Differential Revision: https://reviews.llvm.org/D122142
Some I/O error situations are current handled with fatal
runtime asserts, but should be exposed for user program
error recovery.
Differential Revision: https://reviews.llvm.org/D122049
This patch adds lowering for procedure designator.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122153
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds the OpenMP conversion patterns to the FIR to LLVM
dialect lowering pass in Codegen. Appropriate legalization
conditions are also added. This ensures that a mix of FIR and OpenMP
dialects can be lowered to LLVM and OpenMP dialects. Also adds two
tests.
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: clementval, peixin
Differential Revision: https://reviews.llvm.org/D121793
Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Some refactoring and related fixes for more accurate
user program error recovery in the I/O runtime, especially
for error recovery with IOMSG= character values.
1) Move any work in an EndIoStatement() implementation
that may raise an error into a new CompleteOperation()
member function. This allows error handling APIs like
GetIoMsg() to complete a pending I/O statement and harvest
any errors that may result.
2) Move the pending error code from ErroneousIoStatementState
to a new pendingError_ data member in IoErrorHandler.
This allows IoErrorHandler::InError() to return a correct
result when there is a pending error that will be recovered
from so that I/O list data transfers don't crash in the meantime.
3) Don't create and leak a unit for a failed OPEN(NEWUNIT=n)
with error recovery, and don't modify 'n'. (Depends on
changes to API call ordering in lowering, in a separate patch;
code was added to ensure that OPEN statement control list
specifiers, e.g. SetFile(), must be passed before GetNewUnit().)
4) Fix the code that calls a form of strerror to fill an
IOMSG= variable so that it actually works for Fortran's
character type: blank fill with no null or newline termination.
Differential Revision: https://reviews.llvm.org/D122036
Support the names AND, OR, and XOR for the generic intrinsic
functions IAND, IOR, and IEOR respectively.
Differential Revision: https://reviews.llvm.org/D122034
In flang/runtime/transformational.cpp, there are many RUNTIME_CHECK assertions
for errors that should have been caught in semantics, but there are alno others
that signify program errors that in principle cannot be detected until
execution. Convert this second group into readable fatal error messages.
Also clean up some missing braces and incorrect printf formats found
along the way.
Differential Revision: https://reviews.llvm.org/D122037
Extend "extension<LanguageFeature>()" to incorporate an explanatory
message better than the current generic "nonstandard usage:".
Differential Revision: https://reviews.llvm.org/D122035
This patch adds parser nodes for each indivudual section in sections
construct. This should help with the translation to FIR. `!$omp section`
was not recognized as a construct and hence needed special handling.
`OpenMPSectionsConstruct` contains a list of `OpenMPConstruct`. Each
such `OpenMPConstruct` wraps an `OpenMPSectionConstruct`
(section, not sections). An `OpenMPSectionConstruct` is a wrapper around
a `Block`.
Reviewed By: kiranchandramohan, peixin
Differential Revision: https://reviews.llvm.org/D121680
This patch adds lowering for the `select case`
statement.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D122007
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 patch adds lowering for SetLength used to set
different length on character storage around calls where
the dummy and actual length differ.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122000
Co-authored-by: Jean Perier <jperier@nvidia.com>
Add couple of tests for the lowering.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121991
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 patch adds lowering to suppoert statement functions
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121990
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds support for lowering of the `ior` intrinsic from
Fortran to the FIR dialect of MLIR.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D121928
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds support for lowering of the `{l|u}bound` intrinsics from
Fortran to the FIR dialect of MLIR. Note that `ubound` is already
supported, but the test was missing (added here).
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D121926
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
This patch adds support for lowering of the `merge` intrinsics from
Fortran to the FIR dialect of MLIR.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D121924
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Mark Leair <leairmark@gmail.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
These intrinsics returns the distance to the nearest real number and
their reciprocal. They are lowered to flang runtime calls.
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: clementval
Differential Revision: https://reviews.llvm.org/D121832
Co-authored-by: Mark Leair <leairmark@gmail.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds more lowering for array expressions.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121952
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds some tests for the lowering of
array constructors.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121945
Co-authored-by: mleair <leairmark@gmail.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>
All option forwarding tests should be added to frontend-forwarding.f90
rather than files corresponding to various options. This patch moves
such test for `-mllvm` accordingly.
This patch adds lowering for the following numeric intrinsics:
- aint
- anint
- cmplx
- conjg
- dble
- dprod
- sign
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D121917
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 patch adds couple of lwoering tests for equivalences
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D121918
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 patch adds more lowering tests for dummy arguments
and adds lowering for a specific case.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D121919
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds more lowering tests for IO
Test lowering of IO read SIZE control-spec (12.6.2.15)
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121920
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
The repeat intrinsic creates ncopies of a string. The lowering is to
a runtime call to a function in the flang library. The runtime allocates
the buffer to store the result string. This buffer is freed by code
added in the lowering.
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: clementval
Differential Revision: https://reviews.llvm.org/D121880
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds lowering for command and environment
related intrinsics:
- `get_command_argument`
- `get_environment_variable`
- `command_argument_count`
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121909
Co-authored-by: Josh Mottley <Josh.Mottley@arm.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Tranpose intrinsic performs the transpose matrix operation for arrays
of rank 2. The intrinsic is lowered to a runtime call.
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: clementval
Differential Revision: https://reviews.llvm.org/D121895
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
The trim intrinsic removes trailing blank spaces from a string. The
intrinsic is lowered to a runtime call.
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: jeanPerier
Differential Revision: https://reviews.llvm.org/D121901
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
The Matmul intrinsic performs matrix multiplication on rank 2 arrays.
The intrinsic is lowered to a runtime call.
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: clementval
Differential Revision: https://reviews.llvm.org/D121904
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
This patch adds lowering for couple of intrinsics:
- `btest`
- `ceiling`
- `nearest`
- `scale`
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121885
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: AlexisPerry <aperry@lanl.gov>
This patch adds lowering for the `present` intrinsic.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121884
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds lowering for the `exit`
intrinsic.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121882
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Josh Mottley <Josh.Mottley@arm.com>
Kiran Chandramohan