Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3 |
|
#
7cbb3659 |
| 15-Oct-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix broken shared library build (#112444)
I just introduced a dependency from the Evaluate library to the
Semantics library, which is circular in a shared library build.
Rearrange the code
[flang] Fix broken shared library build (#112444)
I just introduced a dependency from the Evaluate library to the
Semantics library, which is circular in a shared library build.
Rearrange the code a little to ensure that the dependence is only on a
header.
show more ...
|
#
35e86245 |
| 15-Oct-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Silence impossible error about SMP interface incompatibility (#112054)
It is possible for the compiler to emit an impossible error message
about dummy argument character length incompatibil
[flang] Silence impossible error about SMP interface incompatibility (#112054)
It is possible for the compiler to emit an impossible error message
about dummy argument character length incompatibility in the case of a
MODULE SUBROUTINE or FUNCTION defined later in a submodule with MODULE
PROCEDURE, when the character length is defined by USE association in
its interface. The checking for separate module procedure interface
compatibility needs to use a more flexible check than just operator== on
a semantics::ParamValue.
show more ...
|
Revision tags: llvmorg-19.1.2, llvmorg-19.1.1 |
|
#
b0bdc7fc |
| 18-Sep-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix subtle type naming bug in module file output (#108892)
A derived type specification in semantics holds both its source name
(for location purposes) and its ultimate derived type symbol.
[flang] Fix subtle type naming bug in module file output (#108892)
A derived type specification in semantics holds both its source name
(for location purposes) and its ultimate derived type symbol. But for
correct module file generation of a structure constructor using that
derived type spec, the original symbol may be needed so that USE
association can be exposed.
Save both the original symbol and its ultimate symbol in the
DerivedTypeSpec, and collect the right one when traversing expressions
(specifically for handling initialization in module files).
Fixes https://github.com/llvm/llvm-project/issues/108827.
show more ...
|
#
d5dd7d23 |
| 17-Sep-2024 |
Youngsuk Kim <youngsuk.kim@hpe.com> |
[flang] Tidy uses of raw_string_ostream (NFC)
As specified in the docs, 1) raw_string_ostream is always unbuffered and 2) the underlying buffer may be used directly
( 65b13610a5226b84889b923bae884b
[flang] Tidy uses of raw_string_ostream (NFC)
As specified in the docs, 1) raw_string_ostream is always unbuffered and 2) the underlying buffer may be used directly
( 65b13610a5226b84889b923bae884ba395ad084d for further reference )
Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.
show more ...
|
Revision tags: llvmorg-19.1.0 |
|
#
ce392471 |
| 10-Sep-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Silence spurious error on non-CUDA use of CUDA module (#107444)
When a module file has been compiled with CUDA enabled, don't emit
spurious errors about non-interoperable types when that mo
[flang] Silence spurious error on non-CUDA use of CUDA module (#107444)
When a module file has been compiled with CUDA enabled, don't emit
spurious errors about non-interoperable types when that module is read
by a USE statement in a later non-CUDA compilation.
show more ...
|
Revision tags: llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2 |
|
#
539a6b50 |
| 30-Jul-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang] Detect use-before-decl errors on type parameters (#99947)
Ensure that type parameters are declared as such before being referenced
within the derived type definition. (Previously, such refe
[flang] Detect use-before-decl errors on type parameters (#99947)
Ensure that type parameters are declared as such before being referenced
within the derived type definition. (Previously, such references would
resolve to symbols in the enclosing scope.)
This change causes the symbols for the type parameters to be created
when the TYPE statement is processed in name resolution. They are
TypeParamDetails symbols with no KIND/LEN attribute set, and they shadow
any symbols of the same name in the enclosing scope.
When the type parameter declarations are processed, the KIND/LEN
attributes are set. Any earlier reference to a type parameter with no
KIND/LEN attribute elicits an error.
Some members of TypeParamDetails have been retyped &/or renamed.
show more ...
|
Revision tags: llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
60c90336 |
| 11-Jul-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang] Silence over-eager warning about interoperable character length (#97353)
Make the results of the two IsInteroperableIntrinsicType() utility
routines a tri-state std::optional<bool> so that
[flang] Silence over-eager warning about interoperable character length (#97353)
Make the results of the two IsInteroperableIntrinsicType() utility
routines a tri-state std::optional<bool> so that cases where the
character length is simply unknown can be distinguished from those cases
where the length is known and not acceptable. Use this distinction to
not emit a confusing warning about interoperability with C_LOC()
arguments when the length is unknown and might well be acceptable during
execution.
show more ...
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1 |
|
#
069aee07 |
| 05-Mar-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang] Rework F'2023 constraint C1167 checking (#83888)
The code that verifies that the type in a TYPE IS or CLASS IS clause is
a match or an extension of the type of the SELECT TYPE selector need
[flang] Rework F'2023 constraint C1167 checking (#83888)
The code that verifies that the type in a TYPE IS or CLASS IS clause is
a match or an extension of the type of the SELECT TYPE selector needs
rework to avoid emitting a bogus error for a test.
Fixes https://github.com/llvm/llvm-project/issues/83612.
show more ...
|
Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4 |
|
#
e45f6e93 |
| 20-Oct-2023 |
jeanPerier <jperier@nvidia.com> |
[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 ...
|
Revision tags: llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4 |
|
#
c9da9c0d |
| 23-Aug-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Support PDT KIND parameters in later parameter kind expressions
Fortran allows an earlier-declared KIND type parameter of a parameterized derived type to be used in the constant expression d
[flang] Support PDT KIND parameters in later parameter kind expressions
Fortran allows an earlier-declared KIND type parameter of a parameterized derived type to be used in the constant expression defining the integer kind of a later type parameter.
TYPE :: T(K,L) INTEGER, KIND :: K INTEGER(K), LEN :: L ... END TYPE
Differential Revision: https://reviews.llvm.org/D159044https://reviews.llvm.org/D159044
show more ...
|
Revision tags: llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
7eb05cb4 |
| 29-May-2023 |
Kelvin Li <kli@ca.ibm.com> |
[flang] Add DerivedTypeSpec::VectorTypeAsFortran for PPC vector type
VectorTypeAsFortran is added for writing PPC vector types to modules.
Coauthor: @tislam
Differential Revision: https://reviews.
[flang] Add DerivedTypeSpec::VectorTypeAsFortran for PPC vector type
VectorTypeAsFortran is added for writing PPC vector types to modules.
Coauthor: @tislam
Differential Revision: https://reviews.llvm.org/D151757
show more ...
|
Revision tags: llvmorg-16.0.4 |
|
#
3332dc32 |
| 06-May-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] CUDA Fortran - part 3/5: declarations checking
Implements checks for CUDA Fortran attributes on objects, types, and subprograms. Includes a couple downgrades of existing errors into warning
[flang] CUDA Fortran - part 3/5: declarations checking
Implements checks for CUDA Fortran attributes on objects, types, and subprograms. Includes a couple downgrades of existing errors into warnings that were exposed during testing.
Depends on https://reviews.llvm.org/D150159 & https://reviews.llvm.org/D150161.
Differential Revision: https://reviews.llvm.org/D150162
show more ...
|
Revision tags: llvmorg-16.0.3 |
|
#
27cf6ba1 |
| 19-Apr-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang][runtime] Initialize uninitialized pointer components
Pointer components without default initialization pose some difficult (or impossible) problems when they appear as right-hand side target
[flang][runtime] Initialize uninitialized pointer components
Pointer components without default initialization pose some difficult (or impossible) problems when they appear as right-hand side targets in pointer assignment statements; they may contain garbage or stale data that looks enough like a valid descriptor to cause a crash. Solve the problem by avoiding it -- ensure that pointers' descriptors are at least minimally established.
Differential Revision: https://reviews.llvm.org/D149979
show more ...
|
Revision tags: llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4 |
|
#
d84faa42 |
| 02-Mar-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Ignore FINAL subroutines with mismatching type parameters
When a parameterized derived type has FINAL subroutines, only those FINAL subroutines whose dummy argument's type matches the type p
[flang] Ignore FINAL subroutines with mismatching type parameters
When a parameterized derived type has FINAL subroutines, only those FINAL subroutines whose dummy argument's type matches the type parameter values of a particular instantiation are relevant to that instantiation.
Differential Revision: https://reviews.llvm.org/D145741
show more ...
|
Revision tags: llvmorg-16.0.0-rc3 |
|
#
ee437afa |
| 15-Feb-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Don't add a source range to a type instantiation's scope
A type instantiation's scope doesn't require a source range, as we don't need/want it to be the result of SemanticsContext::FindScope
[flang] Don't add a source range to a type instantiation's scope
A type instantiation's scope doesn't require a source range, as we don't need/want it to be the result of SemanticsContext::FindScope(), and adding the original type's source range to the scope of one of its instantiations has the side effect of expanding the source range of all of its parents to include the original type definition, which breaks FindScope() for any scope including a type instantiation.
Differential Revision: https://reviews.llvm.org/D144129
show more ...
|
#
4148f276 |
| 08-Feb-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Check for non-interoperable intrinsic types in BIND(C) derived types
Every component of a BIND(C) interoperable derived type must have an interoperable type. Semantics was checking componen
[flang] Check for non-interoperable intrinsic types in BIND(C) derived types
Every component of a BIND(C) interoperable derived type must have an interoperable type. Semantics was checking components with derived types, but not components with intrinsic types.
Differential Revision: https://reviews.llvm.org/D143832
show more ...
|
Revision tags: llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
10b990a0 |
| 10-Jan-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Diagnose known out-of-range subscripts in more circumstances
Semantics can catch out-of-range subscript values already when they appear in DATA statement objects and constant folding of name
[flang] Diagnose known out-of-range subscripts in more circumstances
Semantics can catch out-of-range subscript values already when they appear in DATA statement objects and constant folding of name constant array indexing; this patch fills the gap by checking known constant subscript values in other contexts.
Differential Revision: https://reviews.llvm.org/D142764
show more ...
|
#
635656f4 |
| 16-Dec-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Expunge needless semantics::ProcInterface
The ProcInterface structure is used only by ProcEntityDetails; it represents what a program might have put in parentheses in a procedure-declaration
[flang] Expunge needless semantics::ProcInterface
The ProcInterface structure is used only by ProcEntityDetails; it represents what a program might have put in parentheses in a procedure-declaration-stmt, either the name of a procedure interface or a declaration-type-spec.
If a procedure entity has an implicit interface, the function result type (if any) can be kept in EntityDetails::type_, which already exists and is currently redundant for ProcEntityDetails symbols.
All that is really needed is a nullable Symbol pointer in ProcEntityDetails to point to the procedure's explicit interface, when it has one.
Also, catch the case where a procedure has an explicit interface and a program attempts to also give it a type.
Differential Revision: https://reviews.llvm.org/D140134
show more ...
|
#
9e855a6c |
| 02-Dec-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Map symbols in expressions when copying interface symbols
Given a MODULE SUBROUTINE or MODULE FUNCTION interface followed later by a corresponding separate module subprogram definition in a
[flang] Map symbols in expressions when copying interface symbols
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
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
#
23c2bedf |
| 01-Jul-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Establish a single source of target information for semantics
Create a TargetCharacteristics class to centralize the few items of target specific information that are relevant to semantics.
[flang] Establish a single source of target information for semantics
Create a TargetCharacteristics class to centralize the few items of target specific information that are relevant to semantics. Use the new class for all target queries, including derived type component layout modeling.
Future work will initialize this class with target information provided or forwarded by the drivers, and use it to fold layout-dependent intrinsic functions like TRANSFER().
Differential Revision: https://reviews.llvm.org/D129018
Updates: Attempts to work around build issues on Windows.
show more ...
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4 |
|
#
03095bd9 |
| 19-May-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix crash in semantics after PDT instantiation
The code in semantics that reinitializes symbol table pointers in the parse tree of a parameterized derived type prior to a new instantiation o
[flang] Fix crash in semantics after PDT instantiation
The code in semantics that reinitializes symbol table pointers in the parse tree of a parameterized derived type prior to a new instantiation of the type was processing the symbols of the derived type instantiation scope in arbitrary address order, which could fail if a reference to a type parameter inherited from an ancestor type was processed prior to the parent component sequence. Fix by instantiating components of PDT instantiations in declaration order.
Differential Revision: https://reviews.llvm.org/D126147
show more ...
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2 |
|
#
9e7eef99 |
| 13-Apr-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Handle parameter-dependent types in PDT initializers
For parameterized derived type component initializers whose expressions' types depend on parameter values, f18's current scheme of analyz
[flang] Handle parameter-dependent types in PDT initializers
For parameterized derived type component initializers whose expressions' types depend on parameter values, f18's current scheme of analyzing the initialization expression once during name resolution fails. For example,
type :: pdt(k) integer, kind :: k real :: component = real(0.0, kind=k) end type
To handle such cases, it is necessary to re-analyze the parse trees of these initialization expressions once for each distinct initialization of the type.
This patch adds code to wipe an expression parse tree of its typed expressions, and update those of its symbol table pointers that reference type parameters, and then re-analyze that parse tree to generate the properly typed component initializers.
Differential Revision: https://reviews.llvm.org/D123728
show more ...
|
Revision tags: llvmorg-14.0.1 |
|
#
142cbd50 |
| 04-Apr-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix TYPE/CLASS IS (T(...)) in SELECT TYPE
TYPE IS and CLASS IS guards in SELECT TYPE constructs are allowed to specify the same type as the type of the selector but f18's implementation of t
[flang] Fix TYPE/CLASS IS (T(...)) in SELECT TYPE
TYPE IS and CLASS IS guards in SELECT TYPE constructs are allowed to specify the same type as the type of the selector but f18's implementation of that predicate required strict equality of the derived type representations. We need to allow for assumed values of LEN type parameters to match explicit and deferred type parameter values in the selector and require equality for KIND type parameters. Implement DerivedTypeSpec::Match() to perform this more relaxed type comparison, and use it in check-select-type.cpp.
Differential Revision: https://reviews.llvm.org/D123721
show more ...
|
#
b8e8f62d |
| 04-Apr-2022 |
Jean Perier <jperier@nvidia.com> |
[flang] Fold instantiated PDT character component length when needed
In case a character component PDT length only depends on kind parameters, fold it while instantiating the PDT. This is especially
[flang] Fold instantiated PDT character component length when needed
In case a character component PDT length only depends on kind parameters, fold it while instantiating the PDT. This is especially important if the component has an initializer because later semantic phases (offset computation or runtime type info generation) might get confused and generate offset/type info that will lead to crashes in lowering.
Differential Revision: https://reviews.llvm.org/D122938
show more ...
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1 |
|
#
c4f67ea1 |
| 07-Feb-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Allow DATA initialization of derived types w/ allocatable components
While one cannot of course statically initialize an allocatable component of an instance of a derived type, its mere pres
[flang] Allow DATA initialization of derived types w/ allocatable components
While one cannot of course statically initialize an allocatable component of an instance of a derived type, its mere presence should not prevent DATA initialization of the other nonallocatable components. Semantics was treating the existence of an allocatable component as a case of "default initialization", which it is, but not one that should run afoul of C877. Add another Boolean argument to IsInitialized() to allow for a more nuanced test.
Differential Revision: https://reviews.llvm.org/D119449
show more ...
|