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