[flang] Add UNSIGNED (#113504)

Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).

This is nearly identical to the UNSIGNED feature that h

[flang] Add UNSIGNED (#113504)

Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).

This is nearly identical to the UNSIGNED feature that has been available
in Sun Fortran for years, and now implemented in GNU Fortran for
gfortran 15, and proposed for ISO standardization in J3/24-116.txt.

See the new documentation for details; but in short, this is C's
unsigned type, with guaranteed modular arithmetic for +, -, and *, and
the related transformational intrinsic functions SUM & al.

show more ...

[flang] add getElementType() to fir::SquenceType and fir::VectorType (#112770)

getElementType() was missing from Sequence and Vector types. Did a
replace of the obvious places getEleTy() was used f

[flang] add getElementType() to fir::SquenceType and fir::VectorType (#112770)

getElementType() was missing from Sequence and Vector types. Did a
replace of the obvious places getEleTy() was used for these two types
and updated to use this name instead.

Co-authored-by: Scott Manley <scmanley@nvidia.com>

show more ...

[flang] replace fir.complex usages with mlir complex (#110850)

Core patch of
https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292.
After that, the last s

[flang] replace fir.complex usages with mlir complex (#110850)

Core patch of
https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292.
After that, the last step is to remove fir.complex from FIR types.

show more ...

[Flang] Switch to common::visit more call sites (#90018)

Switch to common::visit more call sites.

Test plan: ninja check-all

[flang][cuda] Propagate data attribute to global with initialization (#95504)

Global with initial value were missing the CUDA data attribute.

Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)

…ted. (#89998)" (#90250)

This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.

This change rem

Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)

…ted. (#89998)" (#90250)

This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.

This change removes calls to the deprecated member functions. It does
not mark the functions deprecated yet and does not disable the
deprecation warning in TypeSwitch. This seems to cause problems with
MSVC.

show more ...

Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)

This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.

This change is causing build failures on

Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)

This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.

This change is causing build failures on a bot
https://lab.llvm.org/buildbot/#/builders/216/builds/38157

show more ...

[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)

See https://mlir.llvm.org/deprecation and
https://discourse.llvm.org/t/preferred-casting-style-going-forward.

[Flang] Support for NULL() and procedure in structure constructor for procedure pointer component. (#85991)

This PR fixes a subset of procedure pointer component initialization in
structure constru

[Flang] Support for NULL() and procedure in structure constructor for procedure pointer component. (#85991)

This PR fixes a subset of procedure pointer component initialization in
structure constructor.
It covers
1. NULL()
2. procedure

For example:
```
MODULE M
TYPE :: DT
!PROCEDURE(Fun), POINTER, NOPASS :: pp1
PROCEDURE(Fun), POINTER :: pp1
END TYPE

CONTAINS

INTEGER FUNCTION Fun(Arg)
class(dt) :: arg
END FUNCTION

END MODULE

PROGRAM MAIN
USE M
IMPLICIT NONE
TYPE (DT), PARAMETER :: v1 = DT(NULL())
TYPE (DT) :: v2
v2 = DT(fun)
END
```

Passing a procedure pointer itself or reference to a function that
returns a procedure pointer is TODO.

show more ...

[flang] Add structure constructor with allocatable component (#77845)

Enable the structure constructor with allocatable component support.
Handling of `null()` for the allocatable component is add

[flang] Add structure constructor with allocatable component (#77845)

Enable the structure constructor with allocatable component support.
Handling of `null()` for the allocatable component is added.

show more ...

[flang] Lower procedure pointer components (#75453)

Lower procedure pointer components, except in the context of structure
constructor (left TODO).

Procedure pointer components lowering share mo

[flang] Lower procedure pointer components (#75453)

Lower procedure pointer components, except in the context of structure
constructor (left TODO).

Procedure pointer components lowering share most of the lowering logic
of procedure poionters with the following particularities:
- They are components, so an hlfir.designate must be generated to
retrieve the procedure pointer address from its derived type base.
- They may have a PASS argument. While there is no dispatching as with
type bound procedure, special care must be taken to retrieve the derived
type component base in this case since semantics placed it in the
argument list and not in the evaluate::ProcedureDesignator.

These components also bring a new level of recursive MLIR types since a
fir.type may now contain a component with an MLIR function type where
one of the argument is the fir.type itself. This required moving the
"derived type in construction" stackto the converter so that the object
and function type lowering utilities share the same state (currently the
function type utilty would end-up creating a new stack when lowering its
arguments, leading to infinite loops). The BoxedProcedurePass also
needed an update to deal with this recursive aspect.

show more ...

[flang][hlfir] Lower parent component in constant structure constructors (#71421)

Simply remove TODO. Since parent components are now fields of the
extended types fir.type<> in HLFIR, there is noth

[flang][hlfir] Lower parent component in constant structure constructors (#71421)

Simply remove TODO. Since parent components are now fields of the
extended types fir.type<> in HLFIR, there is nothing specific to do to
deal with the appearance of a parent component value in a structure
constructor value that must be turned into a fir.global initial value:
it can simply be inserted as a normal field value.

show more ...

[flang][hlfir] Make the parent type the first component (#69348)

Type extension is currently handled in FIR by inlining the parents
components as the first member of the record type.

This is not

[flang][hlfir] Make the parent type the first component (#69348)

Type extension is currently handled in FIR by inlining the parents
components as the first member of the record type.

This is not correct from a memory layout point of view since the storage
size of the parent type may be bigger than the sum of the size of its
component (due to alignment requirement). To avoid making FIR types
target dependent and fix this issue, make the parent component a single
component with the parent type at the beginning of the record type.

This also simplifies addressing since parent component is now a "normal"
component that can be designated with hlfir.designate.

StructureComponent lowering however is a bit more complex since the
symbols in the structure component may refer to subcomponents of parent
types.

Notes:
1. The fix is only done in HLFIR for now, a similar fix should be done
in ConvertExpr.cpp to fix the path without HLFIR (I will likely still do
it in a new patch since it would be an annoying bug to investigate for
people testing flang without HLFIR).
2. The private component extra mangling is useless after this patch. I
will remove it after 1.
3. The "parent component" TODO in constant CTOR is free to implement for
HLFIR after this patch, but I would rather remove it and test it in a
different patch.

show more ...

[flang][hlfir] Fix c_null_ptr lowering in structure constructors (#68321)

Lowering handles C_PTR initial values that are designators or NULL()
inside structure constructors as an extension to suppo

[flang][hlfir] Fix c_null_ptr lowering in structure constructors (#68321)

Lowering handles C_PTR initial values that are designators or NULL()
inside structure constructors as an extension to support. This extension
is used by initial values generated for runtime derived type info.

But c_null_ptr wrongly fell into this extension path with HLFIR, causing
the initial value to be set to some (non null) address containing
c_null_ptr instead of c_null_ptr itself...

This was caused by the FIR lowering relying on genExtAddrInInitializer
to not place c_null_ptr inside an address. Fix this by only falling
through into the extension handling code if this is an extension: i.e,
the expression is some designated symbol or NULL().

show more ...

[flang][lowering] Fix clash between string literals of different kinds (#67576)

At least fir.global for empty string literals of different kinds. Add
the kind to the prefix if it is not 1.

[flang] Lower PRIVATE component names safely (#66076)

It is possible for a derived type extending a type with private
components to define components with the same name as the private
components.

[flang] Lower PRIVATE component names safely (#66076)

It is possible for a derived type extending a type with private
components to define components with the same name as the private
components.

This was not properly handled by lowering where several fir.record type
component names could end-up being the same, leading to bad generated
code (only the first component was accessed via fir.field_index, leading
to bad generated code).

This patch handles the situation by adding the derived type mangled name
to private component.

show more ...

[flang] Add support for dense complex constants

Add support for representing complex array constants with MLIR
dense attribute. This improves compile time and greatly reduces
memory usage of program

[flang] Add support for dense complex constants

Add support for representing complex array constants with MLIR
dense attribute. This improves compile time and greatly reduces
memory usage of programs with large complex array constants.

Fixes https://github.com/llvm/llvm-project/issues/63610

Reviewed By: vzakhari

Differential Revision: https://reviews.llvm.org/D155951

show more ...

Reland "[flang] Handle array constants of any rank"

Fixes gfortran test-suite regression.

Differential Revision: https://reviews.llvm.org/D150686

Revert "[flang] Handle array constants of any rank"

This reverts commit e26e68a4905cc13064987c9b19fa153b54035d36.

This broke gfortran test-suite, test regression/intrinsic_pack_3.f90.

[flang] Handle array constants of any rank

Add support for representing array constants of any rank with MLIR
dense attribute. This greatly improves compile time and memory
usage of programs with la

[flang] Handle array constants of any rank

Add support for representing array constants of any rank with MLIR
dense attribute. This greatly improves compile time and memory
usage of programs with large array constants. We still support only
arrays of a few basic types, such as integer, real and logic.

Fixes https://github.com/llvm/llvm-project/issues/60376

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D150686

show more ...

[flang] Fixed initialization of c_ptr/c_funptr arrays.

When lowering ends up outlining the initialization of an entity
containing an array of c_ptr/c_funptr it is treating the array
initializer as s

[flang] Fixed initialization of c_ptr/c_funptr arrays.

When lowering ends up outlining the initialization of an entity
containing an array of c_ptr/c_funptr it is treating the array
initializer as scalar due to the missing check for the rank.
When initializing non-0 rank c_ptr/c_funptr entity it has to
recurse via genConstantValue().

Reviewed By: clementval

Differential Revision: https://reviews.llvm.org/D150903

show more ...

[flang] Fixed global name creation for literal constants.

The global names were created using a hash based on the address
of std::vector::data address. Since the memory may be reused
by different st

[flang] Fixed global name creation for literal constants.

The global names were created using a hash based on the address
of std::vector::data address. Since the memory may be reused
by different std::vector's, this may cause non-equivalent
constant expressions to map to the same name. This is what is happening
in the modified flang/test/Lower/constant-literal-mangling.f90 test.

I changed the name creation to use a map between the constant expressions
and corresponding unique names. The uniquing is done using a name counter
in FirConverter. The effect of this change is that the equivalent
constant expressions are now mapped to the same global, and the naming
is "stable" (i.e. it does not change from compilation to compilation).

Though, the issue is not HLFIR specific it was affecting several tests
when using HLFIR lowering.

Differential Revision: https://reviews.llvm.org/D150380

show more ...

[flang][hlfir] Support type bound procedure in type descriptors

In hlfir, procedure designators are propagated as fir.box_proc.
Derived type descriptors are compiler generated constant structure
con

[flang][hlfir] Support type bound procedure in type descriptors

In hlfir, procedure designators are propagated as fir.box_proc.
Derived type descriptors are compiler generated constant structure
constructors. They contain CFPTR components for the type bound
procedure addresses.
Before being cast to an integer type so that they can be stored
in the CFPTR components, the fir.box_proc addresses must be
obtained with a fir.box_addr.

Differential Revision: https://reviews.llvm.org/D144952

show more ...

[flang][NFC] share Constant<SomeDerived> lowering

A previous patch (https://reviews.llvm.org/D136955) already refactored
intrinsic constant lowering to place in its own file and allow using it from

[flang][NFC] share Constant<SomeDerived> lowering

A previous patch (https://reviews.llvm.org/D136955) already refactored
intrinsic constant lowering to place in its own file and allow using it from
both the current lowering and the new lowering to HLFIR.

This patch does the same for derived types. The core function
"genStructComponentInInitializer" is moved from ConvertExpr.cpp and
renamed "genInlinedStructureCtorLitImpl" into ConvertConstant.cpp
without significant logic change.

Then, genScalarLit, genArrayLit (and genInlinedArrayLit/genOutlinedArrayLit)
are updated to support derived types.

The core aspect of derived type constant lowering that differs between
the current lowering and the HLFIR update is the way
addresses/initial target descriptors are built when part of a derived
type constant. This part happens in ConvertVariable.cpp (since the
address of a variable is taken in an initializer and is left TODO).

The mangling of derived type global literal constant is fixed: it did not embed
the derived type name and could cause "conflicts" between unrelated
derived types containing the same data. However, the hash remains
unstable between two compilation of the same file. This is not a
correctness issue and would require a lot of work to hash the derived
type constant data without hashing some irrelevant (but not out of bound)
data in the compile time data structure that holds derived type
constants (Constant<SomeDerived>). This may have to be revisited later.

Differential Revision: https://reviews.llvm.org/D140986

show more ...

[flang] Use std::nullopt instead of None (NFC)

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 m

[flang] Use std::nullopt instead of None (NFC)

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

show more ...