Same as fir.no_reassoc but accepts hlfir.expr type. It is needed because
FIR operation can only produce FIR types, and I do not want to change
that for now.
Depends on D139519
Differential Revision: https://reviews.llvm.org/D139520
hlfir.as_expr allows taking a value from a character, derived type,
or array expressions. This will allow implementing parentheses.
Combining as_expr + hlfir.associate will allow creating a variable copy
into a new temporary variable.
A later patch will add the ability to "move" a variable into an
expression (to give ownership of the variable storage to the expression,
with the commitment that the variable will not be used anymore).
Differential Revision: https://reviews.llvm.org/D139519
This supports the codegen for procedure pointer component in
BoxedProcedure pass. Also fix the FIR in ProcedurePointer.md so that
all the cases can be run using `tco` to generate the LLVM IR.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136842
Add the default unoptimized implementation implementation
of hlfir.assign. It relies on the runtime for array assignment
and always makes a temp of the right hand side for arrays.
Assignment optimization will be done when all HLFIR pieces are in place
and aliasing analysis is available.
Differential Revision: https://reviews.llvm.org/D139426
The implementation follows the pattern used in comparable intrinsics.
Change the runtime API for Norm2 so it does not expect a mask argument
since the Norm2 intrinsic does not accept a mask in Fortran.
Differential Revision: https://reviews.llvm.org/D138150
In a pure context, a pointer acquired from an INTENT(IN) dummy argument
may not be copied. Catch the case in which the pointer is a component
of an allocatable component at some depth of nesting.
(This patch adds a new component iterator kind that is a variant of
a potential subobject component iterator; it visits all potential
subobject components, plus pointers, into which it does not descend.)
Differential Revision: https://reviews.llvm.org/D139161
Given a MODULE SUBROUTINE or MODULE FUNCTION interface followed
later by a corresponding separate module subprogram definition in a
MODULE PROCEDURE, the copies of the interface's dummy argument and
function result symbols that populate the initial scope of that
MODULE PROCEDURE need to have any symbol references in their types
or bounds adjusted to point to their new counterparts.
Differential Revision: https://reviews.llvm.org/D139200
In C++20, types that declare or delete any constructors are no longer aggregates, breaking compilation of many existing uses of aggregate initialization.
Although `Verbatim` declares itself to not have a no-arg default constructor, this is circumvented in `basic-parsers.h` which returns a `RESULT{}` a.k.a. `Verbatim{}`. Adding the no-arg constructor while still deleting the copy/assignment constructors maintains the current state and also supports eventually building this in c++20 mode.
Fix suggested in https://discourse.llvm.org/t/build-failure-when-attempting-to-build-flang-with-c-20/66953.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D139228
Lower pointer assignment with remapping involving polymorphic entities
to runtime call to PointerAssociateRemapping.
For the time being all pointer assignment involcing polymorphic entities are
done with the runtime call. When lhs is not unlimited polymorphic
we might be able to do it inlined as well.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139198
Enforce detectable compilation-time violations of restrictions on the
arguments to the TRANSFER() intrinsic function (16.9.163) with
error messages, and mark other potential problems with warnings.
Differential Revision: https://reviews.llvm.org/D139157
The semantics of many transformational intrinsic functions, especially
reductions like SUM(), are determined by the static presence or absence
of a DIM= argument. In the case of an actual DIM= argument that is
syntactically present but could be dynamically absent at execution time
(due to being OPTIONAL, POINTER, or ALLOCATABLE), f18 should emit some
kind of diagnostic message.
Other compilers either ignore this possibility or treat it as a hard
error; neither really seems correct, so let's do something more nuanced.
For cases where the dynamic absence of a value for DIM doesn't pose
as much of a risk because it lowering is going to assume that it's
equal to 1 anyway, emit only a portability warning.
For other cases where the generated code or runtime support library
will need the value of DIM= during execution, emit a warning that
the use of an OPTIONAL/POINTER/ALLOCATABLE variable or component
here is dicey and should be reconsidered.
While here, also catch bad constant DIM= values.
Differential Revision: https://reviews.llvm.org/D139155
An assumed-size dummy array argument with INTENT(OUT) can't have a type
that might require any runtime (re)initialization, since the size of the
array is not known.
Differential Revision: https://reviews.llvm.org/D139149
Check most of the requiremens of constraint C1577 for statement functions.
The restrictions that prevent recursion are hard errors; the others seem
to be benign legacies and are caught as portability warnings.
Differential Revision: https://reviews.llvm.org/D139136
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Type-bound generics like operator(+) and assignment(=) need to not be
PRIVATE if they are used outside the module in which they are declared.
Differential Revision: https://reviews.llvm.org/D139123
When checking the specific procedures of a generic interface for a
match against a given set of actual arguments, be sure to not match
a function against a subroutine call or vice versa. (We generally
catch and warn about attempts to declare mixed interfaces, but they
are usually conforming and can be inadvertently created when generics
are merged due to USE and host association.)
Differential Revision: https://reviews.llvm.org/D139059
12.6.3p5 requires an I/O data list item to have a defined I/O procedure
if it is polymorphic. (We could defer this checking to the runtime,
but no other Fortran compiler does so, and we would also have to be
able to catch the case of an allocatable or pointer direct component
in the absence of a defined I/O subroutine.)
Also includes a patch to name resolution that ensures that a
SELECT TYPE construct entity is polymorphic in the domain of a
CLASS IS guard.
Also ensures that non-defined I/O of types with PRIVATE components
is caught.
Differential Revision: https://reviews.llvm.org/D139050
A NULL() pointer is generally not a valid expression (as opposed to
a variable) apart from some initialization contexts and some actual
arguments.
Differential Revision: https://reviews.llvm.org/D139047
The standard does *not* require that a real or imaginary part of a complex
literal constant be a scalar if it is a named constant. Downgrade a
recently installed check to a portability warning, and document it.
Differential Revision: https://reviews.llvm.org/D139046
When a scope declares the name and perhaps some characteristics of
an external subprogram using any of the many means that Fortran supplies
for doing such a thing, and that external subprogram's definition is
available, check the local declaration against the external definition.
In particular, if the global definition's interface cannot be called
by means of an implicit interface, ensure that references are via an
explicit and compatible interface.
Further, extend call site checking so that when a local declaration
exists for a known global symbol and the arguments are valid for that
local declaration, the arguments are checked against the global's
interface, just are is already done when no local declaration exists.
Differential Revision: https://reviews.llvm.org/D139042
The internal representation for array constructors in expressions during semantic
analysis needs to be able to accommodate circumstances (e.g. TRIM(), substrings)
in which the length of the elements in the array is either unknown or cannot be
represented as a context-free integer expression.
Differential Revision: https://reviews.llvm.org/D139041
Rework some recent changes to the ENUM_CLASS() macro so that
all of the construction of enumerator-to-name string mapping
data structures is again performed at compilation time.
Differential Revision: https://reviews.llvm.org/D137859
This patch:
- Adds target-feature and target-cpu to FC1Options.
- Moves getTargetFeatures() from Clang.cpp to CommonArgs.cpp.
- Processes target cpu and features in the flang driver. Right now
features are only added for AArch64/x86 because I only did basic
testing on them but it should generally work for others as well.
Option handling is similar to clang.
- Adds appropriate structures in TargetOptions and passes them to
the target machine.
What's missing:
- Adding the CPU info and the features as attributes in the LLVM IR
module.
- Processing target specific flags, e.g. SVE vector bits for AArch64,
ABI etc.
Differential Revision: https://reviews.llvm.org/D137995
Change-Id: Ib081a74ea98617674845518a5d2754edba596418
SELECT TYPE lower and conversion was not handling
`character` type guard. This add support for it.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139106
Use recently added hlfir.associate/hlfir.end_associate to deal
with the cases where the actual argument is an expression.
Differential Revision: https://reviews.llvm.org/D139009
Record type was not correctly retrived so the runtime call was not
produced correctly.
Fix how the record type is retrived so the correct call is
produced.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139084
In D139019 the assumption was made that the rhs was also the MutableBox
but this is not a constraint. Use genExprBox instead. Also the allowed
conversion in D139019 was not correct. Remoed it since it is not needed anymore.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139081
Clang uses signext/zeroext attributes for integer arguments shorter than
the default 'int' type on a target. So Flang has to match this for functions
from Fortran runtime and also for BIND(C) routines. This patch implements
ABI adjustments only for Fortran runtime calls. BIND(C) part will be done
separately.
This resolves https://github.com/llvm/llvm-project/issues/58579
Differential Revision: https://reviews.llvm.org/D137050
Pointer association with an unlimited polymorphic pointer on the lhs
requires more than just updating the base_addr. Delegate the association to
the runtime function `PointerAssociation`.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139019
This will help lowering to HLFIR to not use the AsGenericExpr/AsExpr
patterns that copies sub-expresssions into evaluate::SomeExpr so that
they can be passed to helpers. Sub-expressions like FunctionRef can
be heavy (hundreds of arguments, constant array expression arguments...).
Differential Revision: https://reviews.llvm.org/D138997
These operations allow creating an HLFIR variable from a HLFIR value and
destroying it at the end of the variable lifetime.
This will both be used to implement procedure reference arguments association
when the actual is an expression, and to implement the Fortran associate
construct when the associated entity is an expression.
See https://github.com/llvm/llvm-project/blob/main/flang/docs/HighLevelFIR.md
for more details.
Differential Revision: https://reviews.llvm.org/D138996
The implementation follows the patterns established by the lowering of other
similar intrinsics.
In addition to the code for lowering, the DoTotalReduction template had to be
fixed to correctly break when signaled to do so by the accumulator function.
Differential Revision: https://reviews.llvm.org/D138140
Fixes#59132 by mitigating the behavior of not setting underflow flag on RISC-V platform.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D138503
hlfir.concat codegen happens in the "bufferization" pass: the pass
that place hlfir.expr in memory and transform all operations producing
or accepting hlfir.expr arguments into operations operating on memory.
Since this pass gets rid of the hlfir.expr type, this is a full
translation pass.
So far hlfir.concat codegen re-uses the current concatenation lowering helper
and only supports concatenation of two strings at a time. This matches
what lowering to HLFIR without any optimization produces. More optimized
versions will be developed later.
Differential Revision: https://reviews.llvm.org/D138673
Code generation to create and populate the descriptor (element size and
type code) is based on the boxed result type. This does not work well with
unlimited polymorphic entities since the fir type does not represent what is
actually emboxed or reboxed.
In the case of emboxing, the input type will be used to populate
the descriptor element size and type code.
When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the
element size and type code is retrieve from the input box.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D138587
Move genCallOpAndResult from ConvertExpr.cpp into a new file so that
it can be shared with lowering to FIR and HLFIR during the transition.
After the transition, call lowering to HLFIR will be implemented in
this new file.
Differential Revision: https://reviews.llvm.org/D138643
As suggested on D138129, switching rteurn of CollectBindings
function to SymbolVector.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D138419
As suggested on D138129, switching rteurn of CollectBindings
function to SymbolVector.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D138419
Convert fir.select_type operation to an if-then-else ladder.
The type guards are sorted before the conversion so it follows the
execution of SELECT TYPE construct as mentioned in 11.1.11.2 point 4
of the Fortran standard.
Depends on D138279
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D138280
As Fortran 2018 16.9.82, all the arguments of GET_COMMAND are optional.
When they are all absent, do nothing so to be consistent with gfortran
and ifort. The semantic analysis and runtime have been supported.
This intrinsic was introduced from F2003, and this supports the lowering
of it.
Reviewed By: PeteSteinfeld, jeanPerier
Differential Revision: https://reviews.llvm.org/D137887
