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