This patch enables the Fortran runtime support library to be
built without native 128-bit integer support in the C++ compiler.
Experimental: do not merge yet.
Differential Revision: https://reviews.llvm.org/D154660
(cherry picked from commit 1c35c1a73907a95ce54b5a0edca513591e2bc069)
This renaming started with the native ODS support for properties, this is completing it.
A mass automated textual rename seems safe for most codebases.
Drop also the ods prefix to keep the accessors the same as they were before
this change:
properties.odsOperandSegmentSizes
reverts back to:
properties.operandSegementSizes
The ODS prefix was creating divergence between all the places and make it harder to
be consistent.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D157173
In a standalone build, there is no guarantee that flang code would be
saved in a directory named flang. Check only the path under flang's root
directory.
Reviewed By: #flang, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D157642
(cherry picked from commit 94f377d880376fa6d5653430cad2777e51759d48)
This issue was raised on https://github.com/llvm/llvm-project/issues/64268.
`flang/lib/Optimizer/Transforms/SimplifyIntrinsics.cpp` includes
`flang/Optimizer/HLFIR/HLFIRDialect.h` and might fails if the HLFIR related
tablegen files have not been generated.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D156751
(cherry picked from commit 103907bc5fcf656b1551e191af8176cd7bfb91da)
hlfir.count lowering was using incorrect default integer kind
by ignoring the kind specified in the ModuleOp.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D156017
Character length may be unknown for the type of Fortran::evaluate::FunctionRef
expression, but we can try to propagate it from the argument of
TRANSPOSE if it is known constant. Alternatively, we could relax
hlfir.transpose verification (i.e. allow character types mismatch
for the argument and the result).
Depends on D155912
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D155913
Keep the original array size when materializing the private copy.
Depends on D155882
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D155893
Update the code generated in the init region to materialize the private
copy.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D155882
A semantics check for an assumed-length dummy procedure pointer was
inappropriately part of an "else" clause for a preceding check,
causing it to not be applied in all situations.
Differential Revision: https://reviews.llvm.org/D155975
An attempt to use an edit descriptor (other than A or L) in a FORMAT
statement without arequired 'w' width will elicit warnings from both
the parser and the I/O checker in semantics. Remove the warning from
the parser.
Differential Revision: https://reviews.llvm.org/D155977
NORM2 is broken for arrays that start with a negative number
because it sets the initial running max_ value to that number
rather than to its absolute value.
Differential Revision: https://reviews.llvm.org/D155976
Add more checks to procedure compatibility testing for procedure pointer
assignments, actual procedure arguments, &c. Specifically, don't
allow corresponding dummy data objects to differ in their use
of polymorphism, assumed size arrays, or assumed shape arrays.
Differential Revision: https://reviews.llvm.org/D155974
A quotation mark can appear in a Fortran character literal by doubling
it; for example, PRINT *, "'""'" prints '"'. When those doubled
quotation marks are split by a free form line continuation, the
continuation line should have an ampersand before the second quotation
mark. But most compilers, including this one, allow the second
quotation mark to appear as the first character on the continuation
line, too.
So this works:
print *, "'"&
"'"
but it really should be written as:
print *, "'"&
&"'"
Emit a portability warning and document that we support this near-universal
extension.
Differential Revision: https://reviews.llvm.org/D155973
A dummy argument with an assumed (*) character length or derived type parameter
value specification needs to be associated with an actual argument that can
supply a value for it, so make sure that a NULL without a MOLD= is not being
passed.
Differential Revision: https://reviews.llvm.org/D155971
The check for inappropriate usage of the ASYNCHRONOUS attribute
needed to be moved in declaration checking so that it can catch
attempts to use it on a subroutine.
Differential Revision: https://reviews.llvm.org/D155970
F'2023 7.8 para 5 requires that an implied DO loop with no iterations
in a character array constructor should have items whose lengths are
constant expressions independent of the value of the implied DO loop
index.
Differential Revision: https://reviews.llvm.org/D155968
It is an error to open a new unit with OPEN(NEWUNIT=) and have
neither a file name nor a scratch status. Catch it, and report a
new error code.
Differential Revision: https://reviews.llvm.org/D155967
When searching for a matching specific procedure for a set of actual
arguments in a type-bound generic interface for a defined operator,
don't discard any error messages that may have been produced for
the specific that was found. Tweak the code to preserve those
messages and add them to the context's messages, and add a test.
Differential Revision: https://reviews.llvm.org/D155966
Some operations using the result of hlfir.dot_product can tolerate
that the type of the result changes from !fir.logical to i1 during
intrinsics lowering, but some won't. I added a separate LIT case with
fir.store to mimic one of the nag tests.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D155914
When MatmulTranpose reports incorrect shapes of the arguments
it cannot represent itself as MATMUL, because the reading
of the first argument's shape will be confusing.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D155911
DIM= arguments with constant values can be checked for validity
even when other arguments to an intrinsic function can't be
folded. Handle errors with assumed-rank arguments as well.
Differential Revision: https://reviews.llvm.org/D155964
The runtime type information tables always flag ABSTRACT types as
needing neither destruction in general nor finalization in particular.
This is incorrect. Although an ABSTRACT type may not itself have
a FINAL procedure -- its argument cannot be polymorphic, but
ABSTRACT types in declarations must always be so -- it can still
have finalizable components &/or components requiring deallocation.
Differential Revision: https://reviews.llvm.org/D155965
A name that has been used to reference an undeclared global external
procedure should be accepted as the target of a procedure pointer
assignment statement.
Fixes llvm-test-suite/Fortran/gfortran/regression/proc_ptr_45.f90.
Differential Revision: https://reviews.llvm.org/D155963
The subroutine AreSameComponent() of the predicate AreSameDerivedType()
had a TODO about checking component types that needed completion in order
to properly detect that two specific procedures of a generic are
distinguishable in the llvm-test-suite/Fortran/gfortran/regression
test import7.f90.
Differential Revision: https://reviews.llvm.org/D155962
The ASSOCIATED() intrinsic was mistakenly defined in the intrinsic
function table as requiring operands of known rank, which unintentionally
prevented assumed-rank dummy arguments from being tested.
Fixes llvm-test-suite/Fortran/gfortran/regression/pr88932.f90.
Differential Revision: https://reviews.llvm.org/D155498
If end_associate may execute more times than the expr value producer,
then it cannot take ownership of the expr buffer. Otherwise, it may
result in double-free errors.
Note that the LIT test exposes a different issue with fir.alloca
inside the do-loop produced for hlfir.elemental. This may cause
out-of-stack conditions in valid Fortran programs that are not expected
to run out of stack. I will create an issue for this.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D155778
This patch modifies the construction of the `OpenMPIRBuilder` in MLIR to
initialize the `IsGPU` flag using target triple information passed down from
the Flang frontend. If not present, it will default to `false`.
This replicates the behavior currently implemented in Clang, where the
`CodeGenModule::createOpenMPRuntime()` method creates a different
`CGOpenMPRuntime` instance depending on the target triple, which in turn has an
effect on the `IsGPU` flag of the `OpenMPIRBuilderConfig` object.
Differential Revision: https://reviews.llvm.org/D151903
The lowering of calls/expressions unconditionally inserts DestroyOp
clean-up for hlfir.expr values, which is wrong in the case where
the value is used as a result of the elemental operation created
during the implied-do lowering. A cleaner fix could be to avoid
DestroyOp insertion at all, but I have not figure out an easy
way to do it. The DestroyOp look-up I used seems to be quite
reliable, so it should just work.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D155665
When hlfir.assign is lowered into simple load/store,
we may still need to finalize the LHS.
The patch passes `needFinalization` to `genScalarAssignment`
for LHS of any derived type, so some `Destroy` calls
might be redundant. They can be removed later by propagating/deducing
IsFinalizable information about the LHS type.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D155664
Fix the various complex libm selection logic issues from D155310:
- disableMlirComplex is set to false. This means that using mlir complex
is enabled. Yet, the current code still selects libm.
- If we enable mlir complex, we should not check if use approx is
enabled. Namely, we should use mlir complex either if we enable mlir
complex OR use approx is enabled.
To fix the issues, we flip the logic of `disableMlirComplex` to enable
instead. We set it to false by default since the intention from D155310
is to use libm by default. Then we use a logical `&&` with use approx
so that we select libm when BOTH mlir complex and use approx are
disabled.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D155737
The current representation of TBAA is the very last in-tree user of the `llvm.metadata` operation.
Using ops to model metadata has a few disadvantages:
* Building a graph has to be done through some weakly typed indirection mechanism such as `SymbolRefAttr`
* Creating the metadata has to be done through a builder within a metadata op.
* It is not multithreading safe as operation insertion into the same block is not thread-safe
This patch therefore converts TBAA metadata into an attribute representation, in a similar manner as it has been done for alias groups and access groups in previous patches.
This additionally has the large benefit of giving us more "correctness by construction" as it makes things like cycles in a TBAA graph, or references to an incorrectly typed metadata node impossible.
Differential Revision: https://reviews.llvm.org/D155444
This implements the tand intrinsic by performing a multiplication
by pi/180 to the argument before calling tan inline.
This is a commonly provided extension that is used by OpenRadioss
Differential Revision: https://reviews.llvm.org/D154614
This patch changes the default lowering for complex operations to use
the more accurate libm operations as opposed to the mlir complex
operations. This is necessary due to precision issues in the mlir
complex dialect that cause failures in e.g. the LAPACK tests.
The mlir complex dialect lowering will still be used when
`-fapprox-func` is set (and by extension `-ffast-math` and `-Ofast`)
Differential Revision: https://reviews.llvm.org/D155310
The ignore_tkr directive is applied to the third argument so that the number of
interfaces can be reduced.
Differential Revision: https://reviews.llvm.org/D155624
Update Fortran OpenACC tests to use the updated data clause
attribute format for better readability.
Depends on D155605
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D155603
A recent patch replaced two sprintf() calls with snprintf(), but didn't
use the right length for the remaining space in the buffer.
Differential Revision: https://reviews.llvm.org/D155224
This patch sets 'polymorphic' attribute of hlfir::ExprType when
the value is created from a polymorphic entity.
Memoization of such ExprType involves creating a mutable descriptor
on the stack, which is initialized (as a null box) and passed to
AllocatableApplyMold with the mold being the entity from which
the ExprType value is being created.
This patch fixes "creating polymorphic temporary" TODO and also
several cases of "'fir.convert' op invalid type conversion" error.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D155541
