History log of /llvm-project-15.0.7/flang/lib/Evaluate/variable.cpp (Results 1 – 23 of 23)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, 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, 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, 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, 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, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, 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, llvmorg-14.0.6
# b70f507c 16-Jun-2022 Peter Klausler <[email protected]>

[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 <[email protected]>

[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 <[email protected]>

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 <[email protected]>

[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 <[email protected]>

[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 <[email protected]>

[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 <[email protected]>

[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 <[email protected]>

[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 <[email protected]>

[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 <[email protected]>

[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 <[email protected]>

[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 <[email protected]>

[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 <[email protected]>

[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 <[email protected]>

[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 ...


Revision tags: llvmorg-11.0.0-rc2
# 19d7cc2e 13-Aug-2020 Peter Steinfeld <[email protected]>

[flang] Fix assert on character literal substrings as arguments

Character literal substrings used as arguments were causing asserts. This
happened when the code was trying to get the DynamicType of

[flang] Fix assert on character literal substrings as arguments

Character literal substrings used as arguments were causing asserts. This
happened when the code was trying to get the DynamicType of the substring. We
were only recording the DynamicType of the Designator on which the substring
was based. For character literal substrings, the Designator was a character
literal, and we weren't handling getting its type.

I fixed this by changing the `GetType()` method for `DynamicType` to check to
see if we were getting the type of a `Substring` and calculating the type of
the substring by getting the number of bytes in an element of the string.

I also changed the test `resolve49.f90` with some tests, one of which causes
the original crash.

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

show more ...


Revision tags: llvmorg-11.0.0-rc1, llvmorg-12-init
# 8f0f9ead 07-Jul-2020 peter klausler <[email protected]>

[flang] Fix CHARACTER length folding problem

Do not rewrite LEN(x) or x%len to the expression that specifies
the length of x when that length is not a constant expression.
Its value may have changed

[flang] Fix CHARACTER length folding problem

Do not rewrite LEN(x) or x%len to the expression that specifies
the length of x when that length is not a constant expression.
Its value may have changed since the value of the expression was
first captured in the definition of the object.

Reviewed By: tskeith, sscalpone

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

show more ...


Revision tags: llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2
# 1746c8ed 26-May-2020 Pete Steinfeld <[email protected]>

[flang] Fixed crash on forward referenced `len` parameter

Summary:
Using a forward reference to define a `len` parameter causes a crash.
The underlying cause was that a previously declared type had

[flang] Fixed crash on forward referenced `len` parameter

Summary:
Using a forward reference to define a `len` parameter causes a crash.
The underlying cause was that a previously declared type had an
erroneous expression for its `LEN` param value. When this expression
was referenced to evaluate a subsequent expression, bad things happened.
I fixed this by putting in code to detect this case.

Reviewers: tskeith, klausler, DavidTruby

Subscribers: llvm-commits

Tags: #llvm

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

show more ...


Revision tags: llvmorg-10.0.1-rc1
# 3a1afd8c 24-Apr-2020 peter klausler <[email protected]>

Rework DATA statement semantics to use typed expressions

Summary:
Updates recent work on DATA statement semantic checking in
flang/lib/Semantics/check-data.{h,cpp} to use the compiler's
internal rep

Rework DATA statement semantics to use typed expressions

Summary:
Updates recent work on DATA statement semantic checking in
flang/lib/Semantics/check-data.{h,cpp} to use the compiler's
internal representation for typed expressions rather than working
on the raw parse tree. Saves the analyzed expressions for DATA
statement values as parse tree decorations because they'll soon be
needed in lowering. Corrects wording of some error messages.

Fixes a bug in constant expression checking: structure constructors
are not constant expressions if they set an allocatable component
to anything other than NULL.

Includes infrastructure changes to make this work, some renaming
to reflect the fact that the implied DO loop indices tracked by
expression analysis are not (just) from array constructors, remove
some dead code, and improve some comments.

Reviewers: tskeith, sscalpone, jdoerfert, DavidTruby, anchu-rajendran, schweitz

Reviewed By: tskeith, anchu-rajendran, schweitz

Subscribers: llvm-commits, flang-commits

Tags: #flang, #llvm

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

show more ...


# 76d71354 04-Apr-2020 Tim Keith <[email protected]>

[flang] Add message formatting for std::int64_t

There is no printf formatting string for std::int64_t. Instead we have
to cast to std::intmax_t and use `%jd`. This change simplifies that by
automati

[flang] Add message formatting for std::int64_t

There is no printf formatting string for std::int64_t. Instead we have
to cast to std::intmax_t and use `%jd`. This change simplifies that by
automatically converting std::int64_t to std::intmax_t when formatting
messages.

Original-commit: flang-compiler/f18@8a2343dfffc9ccb04bdfe4c16ca47128255d47bd
Reviewed-on: https://github.com/flang-compiler/f18/pull/1101
Tree-same-pre-rewrite: false

show more ...


# 1f879005 29-Mar-2020 Tim Keith <[email protected]>

[flang] Reformat with latest clang-format and .clang-format

Original-commit: flang-compiler/f18@9fe84f45d7fd685051004678d6b5775dcc4c6f8f
Reviewed-on: https://github.com/flang-compiler/f18/pull/1094


Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3
# 8670e499 28-Feb-2020 Caroline Concatto <[email protected]>

[flang] [LLVMify F18] Replace the use std::ostream with LLVM streams llvm::ostream

This patch replaces the occurrence of std::ostream by llvm::raw_ostream.
In LLVM Coding Standards[1] "All new code

[flang] [LLVMify F18] Replace the use std::ostream with LLVM streams llvm::ostream

This patch replaces the occurrence of std::ostream by llvm::raw_ostream.
In LLVM Coding Standards[1] "All new code should use raw_ostream
instead of ostream".[1]

As a consequence, this patch also replaces the use of:
std::stringstream by llvm::raw_string_ostream or llvm::raw_ostream*
std::ofstream by llvm::raw_fd_ostream
std::endl by '\n' and flush()[2]
std::cout by llvm::outs() and
std::cerr by llvm::errs()

It also replaces std::strerro by llvm::sys::StrError** , but NOT in Fortran
runtime libraries

*std::stringstream were replaced by llvm::raw_ostream in all methods that
used std::stringstream as a parameter. Moreover, it removes the pointers to
these streams.

[1]https://llvm.org/docs/CodingStandards.html
[2]https://releases.llvm.org/2.5/docs/CodingStandards.html#ll_avoidendl

Signed-off-by: Caroline Concatto <[email protected]>

Running clang-format-7

Signed-off-by: Caroline Concatto <[email protected]>

Removing residue of ostream library

Signed-off-by: Caroline Concatto <[email protected]>

Original-commit: flang-compiler/f18@a3507d44b8911e6024033aa583c1dc54e0eb89fd
Reviewed-on: https://github.com/flang-compiler/f18/pull/1047

show more ...


# e03b20e6 10-Mar-2020 peter klausler <[email protected]>

[flang] Changes to get a clean build of f18 with latest clang

Prep for review

Original-commit: flang-compiler/f18@111f49061e07604670614250197a1064959fd981
Reviewed-on: https://github.com/flang-comp

[flang] Changes to get a clean build of f18 with latest clang

Prep for review

Original-commit: flang-compiler/f18@111f49061e07604670614250197a1064959fd981
Reviewed-on: https://github.com/flang-compiler/f18/pull/1059

show more ...


# 64ab3302 25-Feb-2020 CarolineConcatto <[email protected]>

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-b

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-by: Caroline Concatto <[email protected]>

Original-commit: flang-compiler/f18@d2eb7a1c443d1539ef12b6f027074a0eb15b1ea0
Reviewed-on: https://github.com/flang-compiler/f18/pull/980

show more ...