Fixes - [#181278](https://github.com/llvm/llvm-project/issues/181278)
This patch fixes a crash in Flang when parsing array constructors like:
`[ty0(2)(4)]`
The current implementation parses this as a type constructor ty0(2),
followed by what appears to be another call (4), instead of rejecting it
as invalid syntax. The lowering of` StructureConstructor` attempts to
retrieve the parent derived type using `sym->owner().derivedTypeSpec()`,
which return `nullptr` for PDT cases and lead to a crash.
In` flang/lib/Lower/ConvertConstant.cpp`, a safeguard is being added
which ensures that we fall back to the constructor’s derived type
specification when the parent type cannot be obtained, preventing the
null dereference and eliminating the crash. This change addresses only
the immediate crash, proper diagnostic handling for this invalid syntax
is still pending and remains as TODO.
---------
Co-authored-by: Jay Satish Kumar Patel <kumarpat@pe31.hpc.amslabs.hpecorp.net>
Corrected various spelling mistakes such as 'occurred', 'receiver',
'initialized', 'length', and others in comments, variable names,
function names, and documentation throughout the project. These
changes improve code readability and maintain consistency in naming
and documentation.
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Going through and doing `convertToAttribute` for all elements, if they
are the same can be costly. If the elements are the same, we can just
call `convertToAttribute` once.
This does give us a significant speed-up:
```console
$ hyperfine --warmup 1 --runs 5 ./slow.sh ./fast.sh
Benchmark 1: ./slow.sh
Time (mean ± σ): 1.606 s ± 0.014 s [User: 1.393 s, System: 0.087 s]
Range (min … max): 1.591 s … 1.628 s 5 runs
Benchmark 2: ./fast.sh
Time (mean ± σ): 452.9 ms ± 7.6 ms [User: 249.9 ms, System: 83.3 ms]
Range (min … max): 443.9 ms … 461.7 ms 5 runs
Summary
./fast.sh ran
3.55 ± 0.07 times faster than ./slow.sh
```
Fixes#125444
ArrayRef(std::nullopt_t) has been deprecated. This patch replaces
std::nullopt with {}.
A subsequence patch will address those places where we need to replace
std::nullopt with mlir::TypeRange{} or mlir::ValueRange{}.
ArrayRef has a constructor that accepts std::nullopt. This
constructor dates back to the days when we still had llvm::Optional.
Since the use of std::nullopt outside the context of std::optional is
kind of abuse and not intuitive to new comers, I would like to move
away from the constructor and eventually remove it.
This patch replaces std::nullopt with {}. There are a couple of
places where std::nullopt is replaced with TypeRange() to accommodate
perfect forwarding.
Refine handling of NULL(...) in semantics to properly distinguish
NULL(), NULL(objectPointer), NULL(procPointer), and NULL(allocatable)
from each other in relevant contexts.
Add IsNullAllocatable() and IsNullPointerOrAllocatable() utility
functions. IsNullAllocatable() is true only for NULL(allocatable); it is
false for a bare NULL(), which can be detected independently with
IsBareNullPointer().
IsNullPointer() now returns false for NULL(allocatable).
ALLOCATED(NULL(allocatable)) now works, and folds to .FALSE.
These utilities were modified to accept const pointer arguments rather
than const references; I usually prefer this style when the result
should clearly be false for a null argument (in the C sense), and it
helped me find all of their use sites in the code.
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.
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>
…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.
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.
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.
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.
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.
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().
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.
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
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
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
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
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
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
This patch moves intrinsic evaluate::Constant<T> lowering into its own
unit outside of ScalarExpr and genarr lowering so that it can
be used by the new lowering without any changes.
DerivedType lowering cannot be shared at that stage because it is too
correlated with the current lowering (requires structure constructor
and designator lowering).
The code had to be refactored quite a bit so that it could be carved
out, but the only "functional" change is that the length of character
arrays lowered by genarr is now `index` instead of `i64` (see test change).
One non-functional benefit of the change is that `toEvExpr` is not
needed anymore and some compile time copies of big constant arrays
that it was causing are removed (see old calls in previous genarr code),
although I am not sure any compile time speed-ups are visible here.
Differential Revision: https://reviews.llvm.org/D136955
