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>
Peter Klausler