History log of /llvm-project/flang/lib/Evaluate/variable.cpp (Results 1 – 25 of 35)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7
# 3a8a52f4 08-Jan-2025 Peter Klausler <pklausler@nvidia.com>

[flang] Make IsCoarray() more accurate (#121415)

A designator without cosubscripts can have subscripts, component
references, substrings, &c. and still have corank. The current
IsCoarray() predica

[flang] Make IsCoarray() more accurate (#121415)

A designator without cosubscripts can have subscripts, component
references, substrings, &c. and still have corank. The current
IsCoarray() predicate only seems to work for whole variable/component
references. This was breaking some cases of THIS_IMAGE().

show more ...


Revision tags: llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2
# 0f973ac7 02-Oct-2024 Peter Klausler <pklausler@nvidia.com>

[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)

(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as

[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)

(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as expected.)

Allow a parser::Message for a warning to be marked with the
common::LanguageFeature or common::UsageWarning that controls it. This
will allow a later patch to add hooks whereby a driver will be able to
decorate warning messages with the names of its options that enable each
particular warning, and to add hooks whereby a driver can map those
enumerators by name to command-line options that enable/disable the
language feature and enable/disable the messages.

The default settings in the constructor for LanguageFeatureControl were
moved from its header file into its C++ source file.

Hooks for a driver to use to map the name of a feature or warning to its
enumerator were also added.

To simplify the tagging of warnings with their corresponding language
feature or usage warning, to ensure that they are properly controlled by
ShouldWarn(), and to ensure that warnings never issue at code sites in
module files, two new Warn() member function templates were added to
SemanticsContext and other contextual frameworks. Warn() can't be used
before source locations can be mapped to scopes, but the bulk of
existing code blocks testing ShouldWarn() and FindModuleFile() before
calling Say() were convertible into calls to Warn(). The ones that were
not convertible were extended with explicit calls to
Message::set_languageFeature() and set_usageWarning().

show more ...


Revision tags: llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2
# ff567a4e 30-Jul-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang] Fix folding of RANK(assumed-type assumed-rank) (#101027)

The code that deals with the special case of RANK(assumed-rank) in
intrinsic function folding wasn't handling the even more special

[flang] Fix folding of RANK(assumed-type assumed-rank) (#101027)

The code that deals with the special case of RANK(assumed-rank) in
intrinsic function folding wasn't handling the even more special case of
assumed-type assumed-rank dummy arguments.

show more ...


Revision tags: llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5
# 505f6da1 01-May-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang] Ensure all warning/portability messages are guarded by Should… (#90518)

…Warn()

Many warning messages were being emitted unconditionally. Ensure that
all warnings are conditional on a tr

[flang] Ensure all warning/portability messages are guarded by Should… (#90518)

…Warn()

Many warning messages were being emitted unconditionally. Ensure that
all warnings are conditional on a true result from a call to
common::LanguageFeatureControl::ShouldWarn() so that it is easy for a
driver to disable them all, or, in the future, to provide per-warning
control over them.

show more ...


Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, 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
# 74e59e77 04-Dec-2023 Brad Smith <brad@comstyle.com>

[flang] Remove GCC 7.2 workarounds (#73574)

The minimum GCC version was bumped from 7.1 to 7.4 so garbage collect
the 7.2 workarounds.

https://reviews.llvm.org/D156286


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3
# 0c0b2ea9 11-Aug-2023 Peter Klausler <pklausler@nvidia.com>

[flang] Check procedure pointer initializations; clean up ELEMENTAL

Implements compatibility checking for initializers in procedure pointer
declarations. This work exposed some inconsistency in how

[flang] Check procedure pointer initializations; clean up ELEMENTAL

Implements compatibility checking for initializers in procedure pointer
declarations. This work exposed some inconsistency in how ELEMENTAL
interfaces were handled and checked, from both unrestricted intrinsic
functions and others, and some refinements needed for function result
compatbility checking; these have also been ironed out. Some new
warnings are now emitted, and this affected a dozen or so tests.

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

show more ...


Revision tags: llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7
# 50960e93 03-Jan-2023 Peter Klausler <pklausler@nvidia.com>

[flang] Catch character length errors in pointer associations

When character lengths are known at compilation time, report an error
when a data target with a known length does not match the explicit

[flang] Catch character length errors in pointer associations

When character lengths are known at compilation time, report an error
when a data target with a known length does not match the explicit length
of a pointer that is being associated with it; see 10.2.2.3 paragraph 5.

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

show more ...


# 8fed620e 31-Jan-2023 Peter Klausler <pklausler@nvidia.com>

[flang] Handle missing substring upper bound better when folding

When folding a substring of a named constant or character literal,
acquire the value of a missing upper bound from the base object.

[flang] Handle missing substring upper bound better when folding

When folding a substring of a named constant or character literal,
acquire the value of a missing upper bound from the base object.

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

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
# cebf1348 06-Oct-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Correct epistemological edge cases for IS_CONTIGUOUS folding

Don't return a hard .FALSE. when folding IS_CONTIGUOUS() unless the
subscript triplets are discontiguous and array section is non

[flang] Correct epistemological edge cases for IS_CONTIGUOUS folding

Don't return a hard .FALSE. when folding IS_CONTIGUOUS() unless the
subscript triplets are discontiguous and array section is nonempty,
or if the array section is nonempty and there is a vector subscript.

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

show more ...


Revision tags: working, llvmorg-15.0.2
# 94896994 21-Sep-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Fold IS_CONTIGUOUS() to .FALSE. when it is known to be

At present, IS_CONTIGUOUS() can only either fold to .TRUE. or
remain unknown. The underlying analysis, however, is capable
of returnin

[flang] Fold IS_CONTIGUOUS() to .FALSE. when it is known to be

At present, IS_CONTIGUOUS() can only either fold to .TRUE. or
remain unknown. The underlying analysis, however, is capable
of returning a tri-state result (true, false, or unknown).
Extend and expose it to folding so that IS_CONTIGUOUS() can
fold to .FALSE. as well as to .TRUE. when contiguity is
known.

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

show more ...


Revision tags: 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, llvmorg-14.0.6
# b70f507c 16-Jun-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Fix folding of LEN(f(...))

LEN(f(...)), where "f" is a non-intrinsic function, should not be folded
to anything else unless the result is a known constant value. While there
are conceivable

[flang] Fix folding of LEN(f(...))

LEN(f(...)), where "f" is a non-intrinsic function, should not be folded
to anything else unless the result is a known constant value. While there
are conceivable cases in which we could do better (e.g., an internal function
whose length is a host-associated INTENT(IN) dummy argument), there are
other cases that we're getting wrong.

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

show more ...


Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# cd03e96f 23-Mar-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Add & use a better visit() (take 2)

Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit().

[flang] Add & use a better visit() (take 2)

Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().

The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.

Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().

Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.

This change is enabled only for GCC builds with GCC >= 9;
an earlier attempt (D122441) ran into bugs in some versions of
clang and was reverted rather than simply disabled; and it is
not well tested with MSVC. In non-GCC and older GCC builds,
common::visit() is simply an alias for std::visit().

show more ...


# 4ca111d4 28-Mar-2022 Andrzej Warzynski <andrzej.warzynski@arm.com>

Revert "[flang] Add & use a better visit()"

This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has
caused multiple build failures:
* https://lab.llvm.org/buildbot/#/builders/177/build

Revert "[flang] Add & use a better visit()"

This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has
caused multiple build failures:
* https://lab.llvm.org/buildbot/#/builders/177/builds/4346
* https://lab.llvm.org/buildbot/#/builders/180/builds/3803
* https://lab.llvm.org/buildbot/#/builders/175/builds/10419
* https://lab.llvm.org/buildbot/#/builders/191/builds/4318
* https://lab.llvm.org/buildbot/#/builders/173/builds/4274
* https://lab.llvm.org/buildbot/#/builders/181/builds/4297

All these bots failed with a time-out:
```
command timed out: 1200 seconds without output running [b'ninja', b'-j', b'32'], attempting to kill
```
I'm guessing that that's due to template instantiations failing at some
point (https://reviews.llvm.org/D122441 introduced a custom
implementation of std::visit). Everything seems fine when either:
* building on X86 with GCC or Clang (tested with GCC 9.3 and Clang 12)
* building on AArch64 with GCC (tested with GCC 11)

show more ...


# 2ab9990c 23-Mar-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Add & use a better visit()

Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most

[flang] Add & use a better visit()

Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().

The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.

Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().

Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.

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

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3
# a53967cd 07-Mar-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Distinguish usage and portability warning messages

Using recently established message severity codes, upgrade
non-fatal messages to usage and portability warnings as
appropriate.

Differenti

[flang] Distinguish usage and portability warning messages

Using recently established message severity codes, upgrade
non-fatal messages to usage and portability warnings as
appropriate.

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

show more ...


Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2
# 5c5bde1b 30-Dec-2021 Peter Klausler <pklausler@nvidia.com>

[flang] Fold SCALE()

Fold references to the intrinsic function SCALE().

(Also work around some MSVC headaches somehow exposed by
this patch: disable a bogus MSVC warning that began to appear
in unr

[flang] Fold SCALE()

Fold references to the intrinsic function SCALE().

(Also work around some MSVC headaches somehow exposed by
this patch: disable a bogus MSVC warning that began to appear
in unrelated source files, and avoid the otherwise-necessary
use of the "template" keyword in a call to a template member
function of a class template.)

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

show more ...


# bd859cb4 06-Jan-2022 Peter Klausler <pklausler@nvidia.com>

[flasg] Debug folding of substring references

Character substrings weren't being folded correctly;
add tests and rework the implementation so that substrings
of literals and named constant character

[flasg] Debug folding of substring references

Character substrings weren't being folded correctly;
add tests and rework the implementation so that substrings
of literals and named constant character scalars & arrays
are properly folded for use in constant expressions.

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

show more ...


Revision tags: llvmorg-13.0.1-rc1
# 78d60094 15-Nov-2021 Peter Klausler <pklausler@nvidia.com>

[flang] Deal with negative character lengths in semantics

Fortran defines LEN(X) = 0 after CHARACTER(LEN=-1)::X so
apply MAX(0, ...) to character length expressions.

Differential Revision: https://

[flang] Deal with negative character lengths in semantics

Fortran defines LEN(X) = 0 after CHARACTER(LEN=-1)::X so
apply MAX(0, ...) to character length expressions.

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

show more ...


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3
# 9245f355 13-Sep-2021 peter klausler <pklausler@nvidia.com>

[flang] Validate SIZE(x,DIM=n) dimension for assumed-size array x

Catch invalid attempts to extract the unknowable extent of the last
dimension of an assumed-size array dummy argument, and clean up

[flang] Validate SIZE(x,DIM=n) dimension for assumed-size array x

Catch invalid attempts to extract the unknowable extent of the last
dimension of an assumed-size array dummy argument, and clean up
problems with assumed-rank arguments in similar circumstances
exposed by testing the fix.

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

show more ...


Revision tags: llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3
# 1a4af2e4 17-Jun-2021 Jean Perier <jperier@nvidia.com>

[flang] preserve symbol in DescriptorInquiry

Do not use ultimate symbols in DescriptorInquiry. Using the ultimate
symbol may lead to issues later for at least two reasons:

- The original symbols ma

[flang] preserve symbol in DescriptorInquiry

Do not use ultimate symbols in DescriptorInquiry. Using the ultimate
symbol may lead to issues later for at least two reasons:

- The original symbols may have volatile/asynchronous attributes that
the ultimate may not have. Later phases working on the DescriptorInquiry
would then not apply potential care required by these attributes.
- HostAssociatedDetails symbols are used by OpenMP for symbols with
special OpenMP attributes inside OpenMP region (e.g variables with
private attribute), so it is very important to preserve this
aspect in the DescriptorInquiry, that would otherwise apply on the
symbol outside of the region.

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

show more ...


Revision tags: llvmorg-12.0.1-rc2
# ac964175 03-Jun-2021 peter klausler <pklausler@nvidia.com>

[flang] Support known constant lengths in DynamicType

The constexpr-capable class evaluate::DynamicType represented
CHARACTER length only with a nullable pointer into the declared
parameters of type

[flang] Support known constant lengths in DynamicType

The constexpr-capable class evaluate::DynamicType represented
CHARACTER length only with a nullable pointer into the declared
parameters of types in the symbol table, which works fine for
anything with a declaration but turns out to not suffice to
describe the results of the ACHAR() and CHAR() intrinsic
functions. So extend DynamicType to also accommodate known
constant CHARACTER lengths, too; use them for ACHAR & CHAR;
clean up several use sites and fix regressions found in test.

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

show more ...


Revision tags: llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3
# 6f3d322f 30-Jan-2021 peter klausler <pklausler@nvidia.com>

[flang] Improve shape & length characterization

Analyze the shape of the result of TRANSFER(ptr,array) correctly
when "ptr" is an array of deferred shape. Fixing this bug led to
some refactoring an

[flang] Improve shape & length characterization

Analyze the shape of the result of TRANSFER(ptr,array) correctly
when "ptr" is an array of deferred shape. Fixing this bug led to
some refactoring and concentration of common code in TypeAndShape
member functions with code in general shape and character length
analysis, and this led to some regression test failures that have
all been cleaned up.

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

show more ...


Revision tags: llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3
# dd3eb3f3 16-Sep-2020 Peter Steinfeld <psteinfeld@nvidia.com>

[flang] Substrings with lower bound greater than upper bound

According to section 9.4.1, paragraph 3,
If the starting point is greater than the ending point, the substring has
length zero

But the

[flang] Substrings with lower bound greater than upper bound

According to section 9.4.1, paragraph 3,
If the starting point is greater than the ending point, the substring has
length zero

But the compilers code for substring processing was failing a call to `CHECK()`
in this case. I fixed this by just setting the number of items in the
resulting string to 0 for this situation.

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

show more ...


# 4cbfd93a 25-Aug-2020 peter klausler <pklausler@nvidia.com>

[flang] Make `TypeParamInquiry` monomorphic

Change the expression representation TypeParamInquiry from being
a class that's templatized on the integer KIND of its result into
a monomorphic represent

[flang] Make `TypeParamInquiry` monomorphic

Change the expression representation TypeParamInquiry from being
a class that's templatized on the integer KIND of its result into
a monomorphic representation that results in a SubscriptInteger
that can then be converted.

This is a minor simplification, but it's worth doing because
it is believed to also be a work-around for bugs in the MSVC
compiler with overload resolution that affect the expression
traversal framework.

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

show more ...


12