#
300370c2 |
| 20-Nov-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Catch I/O statement error (#116647)
Fortran doesn't have unformatted internal I/O, so catch attempts to use
internal units without a format or namelist specifier.
Fixes https://github.co
[flang] Catch I/O statement error (#116647)
Fortran doesn't have unformatted internal I/O, so catch attempts to use
internal units without a format or namelist specifier.
Fixes https://github.com/llvm/llvm-project/issues/116586.
show more ...
|
#
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 ...
|
#
92e75c09 |
| 05-Sep-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
Reland [flang][cuda] Add c_devptr and bypass output semantic check (#107353)
Add a builtin type for c_devptr since it will need some special handling
for some function like c_f_pointer.
`c_ptr` is
Reland [flang][cuda] Add c_devptr and bypass output semantic check (#107353)
Add a builtin type for c_devptr since it will need some special handling
for some function like c_f_pointer.
`c_ptr` is defined as a builtin type and was raising a semantic error if
you try to use it in a I/O statement. This patch add a check for c_ptr
and c_devptr to bypass the semantic check and allow the variables of
these types to be used in I/O.
This version of the patch keeps the semantic error when -pedantic is
enabled to align with gfortran.
show more ...
|
#
abbcfff7 |
| 05-Sep-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
Revert "[flang][cuda] Add c_devptr and bypass output semantic check" (#107349)
Reverts llvm/llvm-project#107318
It breaks a test
https://lab.llvm.org/buildbot/#/builders/143/builds/1933
|
#
c2fc3320 |
| 05-Sep-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][cuda] Add c_devptr and bypass output semantic check (#107318)
Add a builtin type for c_devptr since it will need some special handling
for some function like c_f_pointer.
`c_ptr` is define
[flang][cuda] Add c_devptr and bypass output semantic check (#107318)
Add a builtin type for c_devptr since it will need some special handling
for some function like c_f_pointer.
`c_ptr` is defined as a builtin type and was raising a semantic error if
you try to use it in a I/O statement. This patch add a check for c_ptr
and c_devptr to bypass the semantic check and allow the variables of
these types to be used in I/O.
show more ...
|
#
b949a6f5 |
| 08-Aug-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang] Warn on useless IOMSG= (#102250)
An I/O statement with IOMSG= but neither ERR= nor IOSTAT= deserves a
warning to the effect that it's not useful.
|
#
d5285fef |
| 11-Jul-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang] Downgrade error message to a portability warning (#98368)
f18 current emits an error when an assignment is made to an array
section with a vector subscript, and the array is finalized with
[flang] Downgrade error message to a portability warning (#98368)
f18 current emits an error when an assignment is made to an array
section with a vector subscript, and the array is finalized with a
non-elemental final subroutine. Some other compilers emit this error
because (I think) they want variables to only be finalized in place, not
by a subroutine call involving copy-in & copy-out of the finalized
elements.
Since many other Fortran compilers can handle this case, and there's
nothing in the standards to preclude it, let's downgrade this error
message to a portability warning.
This patch got complicated because the API for the WhyNotDefinable()
utility routine was such that it would return a message only in error
cases, and there was no provision for returning non-fatal messages. It
now returns either nothing, a fatal message, or a non-fatal warning
message, and all of its call sites have been modified to cope.
show more ...
|
#
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 ...
|
#
320a5197 |
| 26-Jan-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang] Accept OPEN(...,CONVERT="SWAP") in semantics (#79050)
The runtime implements CONVERT="SWAP", but semantics doesn't like it.
Add it to the relevant table.
Fixes llvm-test-suite/Fortran/gf
[flang] Accept OPEN(...,CONVERT="SWAP") in semantics (#79050)
The runtime implements CONVERT="SWAP", but semantics doesn't like it.
Add it to the relevant table.
Fixes llvm-test-suite/Fortran/gfortran/regression/record_marker_1.f90,
.../unf_io_convert_1.f90, .../unf_io_convert_2.f90, and
.../unf_io_convert_3.f90.
show more ...
|
#
3de9aa6b |
| 13-Nov-2023 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang] Catch READ(... SIZE=) with NML= or FMT=* (#71235)
The SIZE= specifier may not appear on a list-directed or namelist READ
statement.
|
#
e727bda1 |
| 15-Aug-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Faster implementation of FindScope()
The utility semantics::SemanticsContext::FindScope() maps a contiguous range of cooked source characters to the innermost Scope containing them. Its imp
[flang] Faster implementation of FindScope()
The utility semantics::SemanticsContext::FindScope() maps a contiguous range of cooked source characters to the innermost Scope containing them. Its implementation is unacceptably slow on large (tens of thousands of lines) source files with many program units; it traverses each level of the scope tree linearly.
Replace this implementation with a single instance of std::multimap<> used as an index from each Scope's source range back to the Scope.
Compilation time with "-fsyntax-only" on the 50,000-line test case that motivated this change drops from 4.36s to 3.72s, and FindScope() no longer stands out egregiously in the profile.
Differential Revision: https://reviews.llvm.org/D159027
show more ...
|
#
6b8e3382 |
| 03-Aug-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Foil attempt to READ a NAMELIST with an undefinable member
Detect and emit errors about undefinable NAMELIST group members in READ statements.
Fixes llvm-test-suite/Fortran/gfortran/regress
[flang] Foil attempt to READ a NAMELIST with an undefinable member
Detect and emit errors about undefinable NAMELIST group members in READ statements.
Fixes llvm-test-suite/Fortran/gfortran/regression/namelist_2.f90.
Differential Revision: https://reviews.llvm.org/D157344
show more ...
|
#
7871deb8 |
| 30-Jun-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Add optional portability warning for upcoming Fortran 202X/3 breaking change
The soon-to-be-published next revision of the ISO Fortran language standard contains a couple of breaking changes
[flang] Add optional portability warning for upcoming Fortran 202X/3 breaking change
The soon-to-be-published next revision of the ISO Fortran language standard contains a couple of breaking changes to previous specifications that may cause existing programs to silently change their behavior.
For the change that introduces automatic reallocation of deferred length allocatable character scalar variables when they appear as the targets of internal WRITE statements, as IOMSG=/ERRMSG= variables, as outputs of INQUIRE specifiers, or as INTENT(OUT) arguments to intrinsic procedures, this patch adds an optional portability warning.
Differential Revision: https://reviews.llvm.org/D154242
show more ...
|
#
191d4872 |
| 09-May-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Finer control over warnings
Establish a set of optional usage warnings, and enable some only in "-pedantic" mode that, in our subjective experience with application codes, seem to issue freq
[flang] Finer control over warnings
Establish a set of optional usage warnings, and enable some only in "-pedantic" mode that, in our subjective experience with application codes, seem to issue frequently without indicating usage that really needs to be corrected. By default, with this patch the compiler should appear to be somewhat less persnickety but not less informative.
Differential Revision: https://reviews.llvm.org/D150710
show more ...
|
#
4bac5f83 |
| 16-Apr-2023 |
Kazu Hirata <kazu@google.com> |
Apply fixes from performance-faster-string-find (NFC)
|
#
7cf1608b |
| 13-Apr-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Rework handling of non-type-bound user-defined I/O
A fairly recent introduction of runtime I/O APIs called OutputDerivedType() and InputDerivedType() didn't cover NAMELIST I/O's need to acce
[flang] Rework handling of non-type-bound user-defined I/O
A fairly recent introduction of runtime I/O APIs called OutputDerivedType() and InputDerivedType() didn't cover NAMELIST I/O's need to access non-type-bound generic interfaces for user-defined derived type I/O when those generic interfaces are defined in some scope other than the one that defines the derived type.
The patch adds a new data structure shared between lowering and the runtime that can represent all of the cases that can arise with non-type-bound defined I/O. It can represent scopes in which non-type-bound defined I/O generic interfaces are inaccessible, too, due to IMPORT statements.
The data structure is now an operand to OutputDerivedType() and InputDerivedType() as well as a data member in the NamelistGroup structure.
Differential Revision: https://reviews.llvm.org/D148257
show more ...
|
#
aa128bb2 |
| 03-Feb-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Catch misuse of a procedure designator as an output item
f18 was diagnosing the misuse of a procedure pointer as an output item, but not the more general case of a procedure designator other
[flang] Catch misuse of a procedure designator as an output item
f18 was diagnosing the misuse of a procedure pointer as an output item, but not the more general case of a procedure designator other than a pointer.
Differential Revision: https://reviews.llvm.org/D143780
show more ...
|
#
9c1ad89d |
| 14-Nov-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Emit portability warning for assigned FORMAT use
Emit a portability warning about usage of a deprecated feature when an I/O data transfer statement uses a scalar integer variable as an assig
[flang] Emit portability warning for assigned FORMAT use
Emit a portability warning about usage of a deprecated feature when an I/O data transfer statement uses a scalar integer variable as an assigned format.
Differential Revision: https://reviews.llvm.org/D139144
show more ...
|
#
5ea0ba2c |
| 30-Nov-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Enforce more restrictions on I/O data list items
12.6.3p5 requires an I/O data list item to have a defined I/O procedure if it is polymorphic. (We could defer this checking to the runtime,
[flang] Enforce more restrictions on I/O data list items
12.6.3p5 requires an I/O data list item to have a defined I/O procedure if it is polymorphic. (We could defer this checking to the runtime, but no other Fortran compiler does so, and we would also have to be able to catch the case of an allocatable or pointer direct component in the absence of a defined I/O subroutine.)
Also includes a patch to name resolution that ensures that a SELECT TYPE construct entity is polymorphic in the domain of a CLASS IS guard.
Also ensures that non-defined I/O of types with PRIVATE components is caught.
Differential Revision: https://reviews.llvm.org/D139050
show more ...
|
#
573fc618 |
| 17-Oct-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix pointer definition semantic checking via refactoring
The infrastructure in semantics that is used to check that the left-hand sides of normal assignment statements are really definable v
[flang] Fix pointer definition semantic checking via refactoring
The infrastructure in semantics that is used to check that the left-hand sides of normal assignment statements are really definable variables was not being used to check whether the LHSs of pointer assignments are modifiable, and so most cases of unmodifiable pointers are left undiagnosed. Rework the semantics checking for pointer assignments, NULLIFY statements, pointer dummy arguments, &c. so that cases of unmodifiable pointers are properly caught. This has been done by extracting all the various definability checking code that has been implemented for different contexts in Fortran into one new facility.
The new consolidated definability checking code returns messages meant to be attached as "because: " explanations to context-dependent errors like "left-hand side of assignment is not definable". These new error message texts and their attached explanations affect many existing tests, which have been updated. The testing infrastructure was extended by another patch to properly compare warnings and explanatory messages, which had been ignored until recently.
Differential Revision: https://reviews.llvm.org/D136979
show more ...
|
#
7ff9064b |
| 04-Oct-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Delay parse tree rewriting for I/O UNIT=func()
When an I/O statement's UNIT= specifier is a variable that is a function reference, parse tree rewriting may determine the wrong type of the re
[flang] Delay parse tree rewriting for I/O UNIT=func()
When an I/O statement's UNIT= specifier is a variable that is a function reference, parse tree rewriting may determine the wrong type of the result because generic resolution has not yet been performed. So move this bit of parse tree rewriting into I/O semantic checking so that the right handling (integer -> external file unit number, character pointer -> internal I/O) applies.
Differential Revision: https://reviews.llvm.org/D135210
show more ...
|
#
cc180f4c |
| 18-Aug-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Support for character array formats
A character array can be used as a format in an I/O data transfer statement, with the interpretation that its elements are concatenated in element order t
[flang] Support for character array formats
A character array can be used as a format in an I/O data transfer statement, with the interpretation that its elements are concatenated in element order to constitute the format.
Support in the runtime with an extra optional descriptor argument to six I/O API calls; support in semantics by removing an earlier check for a simply contiguous array presented as a format.
Some work needs to be done in lowering to pass a character array descriptor to the I/O runtime API when present
Differential Revision: https://reviews.llvm.org/D132167
show more ...
|
#
bad52055 |
| 03-Aug-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang][runtime] Support internal I/O to CHARACTER(KIND/=1)
Allow internal I/O to support non-default kinds of CHARACTER.
The I/O runtime design anticipated this standard feature, but this patch is
[flang][runtime] Support internal I/O to CHARACTER(KIND/=1)
Allow internal I/O to support non-default kinds of CHARACTER.
The I/O runtime design anticipated this standard feature, but this patch is somewhat larger than I thought it would be because many code sites had to have assumptions about units (characters vs. bytes) brought into harmony, and some encoding utilities had to be pulled out of IoStatementState and templatized into their own new header file so that they are available to formatted output code without having to "thread" an IoStatementState reference through many call chains.
Differential Revision: https://reviews.llvm.org/D131107
show more ...
|
#
c105d9b3 |
| 18-Jul-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Admit trailing blanks when checking I/O specifiers
Fortran specifically allows character-valued I/O specifiers to have trailing blanks, e.g. OPEN(666,STATUS='SCRATCH '). The runtime I/O libr
[flang] Admit trailing blanks when checking I/O specifiers
Fortran specifically allows character-valued I/O specifiers to have trailing blanks, e.g. OPEN(666,STATUS='SCRATCH '). The runtime I/O library already handles them, but the I/O static checks in semantics do not.
Differential Revision: https://reviews.llvm.org/D130381
show more ...
|
#
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 ...
|