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)
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
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
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
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
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
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
Other compilers include the logical default also with the
default-integer-8 setting. This patch does the same for
flang.
Reviewed By: awarzynski, sscalpone
Differential Revision: https://reviews.llvm.org/D155279
The previous code path created the elemental kernel by generating a
scalar intrinsic call using pre-prepared arguments using genIntrinsicRefCore,
which then generated the intrinsic call using genIntrinsicCall().
The problem with this approach was that the dynamically optional
arguments were marked as having no argLowering, which meant that they
were unconditionally passed by value without any check to see if they
were present.
It would be nice to put an if operation in the path for !argLowering,
doing something similar to genOptionalValue(). However, this can't be
done because it isn't clear what value should be used for the default.
If zero was used (like in genOptionalValue) this could effect the result
of MIN or MAX.
Instead, this patch re-uses the implementation for scalar dynamically
optional arguments (in non-elemental calls). This does the correct
thing, entirely ignoring absent optional arguments.
Depends On: D155292
Differential Revision: https://reviews.llvm.org/D155293
Only minimal argument processing is needed here because they will be
lowered properly either by the elemental intrinsic call builder or the
lowering of the scalar call inside the elemental kernel.
Dynamically optional arrays are coming in the next patch.
Depends On: D155291
Differential Revision: https://reviews.llvm.org/D155292
Add a new FirOpBuilder constructor to propagate the fast math flag
from an operation. Use this constructor in the LowerHLFIRIntrinsics
pass.
This fixes the performance issue with the hlfir intrinsics flow
for polyhedron/test_fpu2.
Reviewed By: tblah, vzakhari
Differential Revision: https://reviews.llvm.org/D155438
If the size of one of the operand arrays is not known at compile
time, do not issue a size mismatch error sinc they could match at
runtime.
Fixes the compilation error in polyhedron/induct2.
Reviewed By: tblah, vzakhari
Differential Revision: https://reviews.llvm.org/D155302
Add test for simple scalar allocatable or pointer. Set up the TODO
to be triggered when the allocatable or pointer are arrays.
Support for pointer/allocatable arrays will come next.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D155230
Fix some problems with INCLUDE line recognition pointed out by some
recently-added tests to the LLVM test suite.
Differential Revision: https://reviews.llvm.org/D155497
It is not standard conforming under IMPLICIT NONE(TYPE) for a name to
appear in a DATA statement prior to its explicit type declaration,
but it is benign, supported in other compilers, and attested in real
applications. Support it with an optional portability warning.
Fixes GitHub LLVM bug https://github.com/llvm/llvm-project/issues/63783.
Don't emit bogus compile-time error messages about out-of-range values
for the DIM= argument to LBOUND/BOUND when the array in question is an
assumed-rank dummy array argument.
Differential Revision: https://reviews.llvm.org/D155494
The statement "A(J) = expr" could be an assignment to an element of an
array A, an assignment to the target of a pointer-valued function A, or
the definition of a new statement function in the local scope named A,
depending on whether it appears in (what might still be) the specification
part of a program or subprogram and what other declarations and definitions
for A might exist in the local scope or have been imported into it.
The standard requires that the name of a statement function appear in
an earlier type declaration statement if it is also the name of an
entity in the enclosing scope. Some other Fortran compilers mistakenly
enforce that rule in the case of an assignment to the target of a
pointer-valued function in the containing scope, after misinterpreting
the assignment as a new local statement function definition.
This patch cleans up the handling of the various possibilities and
resolves what was a crash in the case of a statement function definition
whose name was the same as that of a procedure in the outer scope whose
result is *not* a pointer.
Differential Revision: https://reviews.llvm.org/D155493
