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 global procedure pointer in BoxedProcedure
pass. Reset the boxproc type.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D138273
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
Polymorphic entities are always emboxed. This patch
handles host association of polyrmophic entities as passed object.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139423
The verifier of fir.emboxchar accepts `fir.char<kind, constant>` types,
but its codegen failed because of a missing cast. It is convenient and
safe to not require making the cast in FIR, so add it in codegen.
Differential Revision: https://reviews.llvm.org/D139514
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
Support fir.class in genScalarUserDefinedAssignmentCall so
emboxing is done correctly.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139435
In some cases, the base type is already a fir.box type. This patch updates
the code to set the result box type to fir.box<T>, where T is the type
of the allocated temp.
This was reported in https://github.com/llvm/llvm-project/issues/59342
Reviewed By: jeanPerier, tblah
Differential Revision: https://reviews.llvm.org/D139401
For now at least, the plan is to keep hlfir.expr usage limited as
sub-expression operand, assignment rhs, and a few other contexts (
e.g. Associate statements). The rest of lowering (statements lowering
in the bridge) will still expect to get and manipulate characters and
arrays in memory. That means that hlfir.expr must be converted to
variable in converter.genExprAddr/converter.genExprBox.
This is done using an hlfir.associate, and generating the related
hlfir.end_associate in the statement context.
hlfir::getFirBase of is updated to avoid bringing in the HLFIR
fir.boxchar/fir.box into FIR when the entity was created with
hlfir::AssociateOp.
Differential Revision: https://reviews.llvm.org/D139328
When generating character assignment operations, the generic code
generates some code to handle truncation and padding when the length
differ at runtime. A bypass already exists when the length are compile
time constant and match, but it was not used for the trivial case where
the RHS and LHS length is the same SSA value. In such case, even though,
the length is not know at compile time, it is known to be the same.
This will simplify the code creating character temporaries from a
variable in HLFIR that will use this assignment code.
Note that this probably has little impact on performance (llvm may be clever enough
to later catch that for us). But it makes the generated IR a lot more readable at
little cost.
Differential Revision: https://reviews.llvm.org/D139330
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
Patch D138274 removed some Flang cmake configuration information that we
need for our internal builds. This change restores them.
Differential Revision: https://reviews.llvm.org/D139355
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
In order to emit overflow warnings from assignment statements whose
right-hand sides are constants that undergo conversions, run the
right-hand sides of assignments through constant folding after the
conversions have been made explicit in expression analysis.
Differential Revision: https://reviews.llvm.org/D139151
Runtime is expecting a 1d array. This patch fixes the generation
of the array holding the bounds to be passed to the runtime function call.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D139324
The code is iterating on the rank of the pointer to set the bounds.
If the rank is retrieved after the `pointer = target` it does not
reflect the actual rank of the pointer.
This could happen in code like the following:
```
type t1
integer :: a
end type
type(t), pointer :: p(:)
class(t), pointer :: q(:,:)
q(0:1,-2:2) => p(10:1:-1)
```
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D139327
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
The only special thing that is needed is to update the bridge symbol
lookup to deal with the HLFIR symbol lookup (symbols are mapped to
fir::FortranVariableInterface operations, not Fortran::Lower::SymbolBox).
Differential Revision: https://reviews.llvm.org/D139201
Fix#59177, add check for dimensionality for shape argument against rank of FPTR argument in c_f_pointer
Reviewed By: peixin
Differential Revision: https://reviews.llvm.org/D138743
Module files for submodules should not contain PRIVATE attributes,
since everything in them is local to the parent module and
accessible to all descendant submodules.
Differential Revision: https://reviews.llvm.org/D139160
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
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
Modules, submodules, main programs, and BLOCK DATA subprograms have names
that cannot be used within their scope, so we allow those names to be
used for other entities in the scope. This might not be entirely
conformant with the language standard, so warn about it.
Differential Revision: https://reviews.llvm.org/D139146
The TARGET= argument of the ASSOCIATED() intrinsic function must be a valid
pointer assignment statement target. Ensure that it does not contain a vector
subscript or any coindexing, either of which would imply a data copy into
temporary storage.
Differential Revision: https://reviews.llvm.org/D139145
Emit a portability warning about usage of a deprecated feature
when an I/O data transfer statement uses a scalar integer
variable as an assigned format.
Differential Revision: https://reviews.llvm.org/D139144
19.6.8 forbids using an INTENT(IN) pointer dummy argument in a pointer association
context, and associated such a pointer with a dummy argument of INTENT(IN OUT) or
INTENT(OUT) is a circumstance that needs to be caught as an error.
Differential Revision: https://reviews.llvm.org/D139138
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
When a submodule defines a module procedure whose interface was declared
in an ancestor (sub)module, don't repeat the definition of that interface
in the submodule's *.mod file output.
Differential Revision: https://reviews.llvm.org/D139132
When a character-valued function is passed as an actual argument, and both
the actual function and the dummy argument have explicit result lengths, take them
into account when testing for compatibility.
Differential Revision: https://reviews.llvm.org/D139129
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
Standard Fortran allows type-bound procedure bindings to only
be called, and disallows them from being used in other contexts
where a procedure name can be: as the target of a procedure pointer
assignment statement, and as an actual argument that corresponds
to a dummy procedure. So long as the interfaces match, there's
no good reason for these uses to be errors, and there some obvious
use cases in polymorphic programming. So emit portability warnings
rather than errors, and document this usage as an extension.
Differential Revision: https://reviews.llvm.org/D139127
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
In a derived type definition, a type bound procedure declaration
statement with neither interface nor attributes is required by constraint
C768 to have the optional "::" between the PROCEDURE keyword and the
bindings if any binding has a renaming with "=>". The colons are
not actually necessary for a correct and unambiguous parse, so
emit a warning when they are missing.
Differential Revision: https://reviews.llvm.org/D139065
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
f18 doesn't have any limit on continuation lines in fixed or free form
source (other than available memory), but the standard does. Emit
a portability warning when it is exceeded.
Differential Revision: https://reviews.llvm.org/D139055
