History log of /llvm-project/flang/lib/Semantics/check-io.cpp (Results 1 – 25 of 47)
Revision Date Author Comments
# 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 ...


12