History log of /llvm-project/flang/lib/Semantics/type.cpp (Results 1 – 25 of 59)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


123