History log of /llvm-project/flang/runtime/io-api.cpp (Results 1 – 25 of 89)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# fee393e4 27-Jan-2025 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Don't crash on ASYNCHRONOUS='NO' in child I/O (#124208)

When ASYNCHRONOUS='NO' appears in a data transfer statement control item
list, don't crash if it isn't appropriate for the k

[flang][runtime] Don't crash on ASYNCHRONOUS='NO' in child I/O (#124208)

When ASYNCHRONOUS='NO' appears in a data transfer statement control item
list, don't crash if it isn't appropriate for the kind of I/O under way
(such as child I/O).

Fixes https://github.com/llvm/llvm-project/issues/124135.

show more ...


# bf95854e 14-Jan-2025 Peter Klausler <pklausler@nvidia.com>

[flang] EOF goes to ERR= in READ(..., REC=) (#122608)

A direct access READ that tries to read past the end of the file must
recover the error via an ERR= label, not an END= label (which is not
all

[flang] EOF goes to ERR= in READ(..., REC=) (#122608)

A direct access READ that tries to read past the end of the file must
recover the error via an ERR= label, not an END= label (which is not
allowed to be present).

Fixes https://github.com/llvm/llvm-project/issues/122150.

show more ...


Revision tags: 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
# 5f11d38d 18-Sep-2024 Peter Klausler <pklausler@nvidia.com>

[flang] Fix code that deletes unit from bad OPEN (#108994)

When an OPEN statement fails, a unit that was created for the OPEN needs
to be removed from the unit map. The code that tried to do this w

[flang] Fix code that deletes unit from bad OPEN (#108994)

When an OPEN statement fails, a unit that was created for the OPEN needs
to be removed from the unit map. The code that tried to do this was
incorrect -- it needs to re-acquire the unit via LookUpForClose as a
CLOSE statement does. (The failure to do this completely was leaving a
zombie unit active that could break a later OPEN on the same unit
number.)

show more ...


Revision tags: 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
# 86e511bc 17-May-2024 Slava Zakharin <szakharin@nvidia.com>

[flang] Fixed https://lab.llvm.org/buildbot/#/builders/270/builds/14406


# fe2ff545 17-May-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Decouple scalar output APIs from descriptors (#92444)

For testing purposes the implementations of the output APIs like
OutputInteger32 have been simply constructing descriptors and

[flang][runtime] Decouple scalar output APIs from descriptors (#92444)

For testing purposes the implementations of the output APIs like
OutputInteger32 have been simply constructing descriptors and executing
the operation through the general DescriptorIO template. This patch
decouples those APIs from that mechanism so that programs using simple
"PRINT *" statements for output can link to a smaller portion of the I/O
runtime support library. (This is the only form of I/O accepted in GPU
device code by previous CUDA Fortran and Fortran OpenACC compilers.)

show more ...


Revision tags: llvmorg-18.1.5, llvmorg-18.1.4
# f3c31d70 05-Apr-2024 Slava Zakharin <szakharin@nvidia.com>

Reland "[flang][runtime] Enable I/O APIs in F18 runtime offload builds." (#87729)

This reverts commit 22089ae6c591d11143724b4bde418aa067958a8f.


# 22089ae6 04-Apr-2024 Mehdi Amini <joker.eph@gmail.com>

Revert "[flang][runtime] Enable I/O APIs in F18 runtime offload builds." (#87629)

Reverts llvm/llvm-project#87543

The pre-merge Windows build is broken.


# 718638d4 03-Apr-2024 Slava Zakharin <szakharin@nvidia.com>

[flang][runtime] Enable I/O APIs in F18 runtime offload builds. (#87543)


Revision tags: llvmorg-18.1.3
# 3ada883f 26-Mar-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Runtime support for REDUCE() (#86214)

Supports the REDUCE() transformational intrinsic function of Fortran
(see F'2023 16.9.173) in a manner similar to the existing support for
SU

[flang][runtime] Runtime support for REDUCE() (#86214)

Supports the REDUCE() transformational intrinsic function of Fortran
(see F'2023 16.9.173) in a manner similar to the existing support for
SUM(), PRODUCT(), &c. There are APIs for total reductions to scalar
results, and APIs for partial reductions that reduce the rank of the
argument by one.

This implementation requires more functions than other reductions
because the various possible types of the user-supplied OPERATION=
function need to be elaborated.

Once the basic API in reduce.h has been approved, later patches will
implement lowering.

REDUCE() is primarily for completeness, not portability; only one other
Fortran compiler implements this F'2018 feature today, and only some
types work correctly with it.

show more ...


# 8ebf7411 25-Mar-2024 Slava Zakharin <szakharin@nvidia.com>

[flang][runtime] Prepare enabling PRINT of integer32 for device. (#86247)

This commit adds required files into the offload build closure,
which means adding RT_API_ATTRS and other markers.

The i

[flang][runtime] Prepare enabling PRINT of integer32 for device. (#86247)

This commit adds required files into the offload build closure,
which means adding RT_API_ATTRS and other markers.

The implementation does not work for CUDA yet, because of
std::variant,swap,reverse usage. These issues will be resolved
separately (e.g. by using libcudacxx header files).

show more ...


Revision tags: llvmorg-18.1.2
# 71e0261f 15-Mar-2024 Slava Zakharin <szakharin@nvidia.com>

[flang][runtime] Added Fortran::common::optional for use on device.

This is a simplified implementation of std::optional that can be used
in the offload builds for the device code. The methods are p

[flang][runtime] Added Fortran::common::optional for use on device.

This is a simplified implementation of std::optional that can be used
in the offload builds for the device code. The methods are properly
marked with RT_API_ATTRS so that the device compilation succedes.

Reviewers: klausler, jeanPerier

Reviewed By: jeanPerier

Pull Request: https://github.com/llvm/llvm-project/pull/85177

show more ...


Revision tags: llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2
# 4679132a 31-Jan-2024 jeanPerier <jperier@nvidia.com>

[flang] Lower ASYNCHRONOUS variables and IO statements (#80008)

Finish plugging-in ASYNCHRONOUS IO in lowering (GetAsynchronousId was
not used yet).

Add a runtime implementation for GetAsynchron

[flang] Lower ASYNCHRONOUS variables and IO statements (#80008)

Finish plugging-in ASYNCHRONOUS IO in lowering (GetAsynchronousId was
not used yet).

Add a runtime implementation for GetAsynchronousId (only the signature
was defined). Always return zero since flang runtime "fakes"
asynchronous IO (data transfer are always complete, see
flang/docs/IORuntimeInternals.md).

Update all runtime integer argument and results for IDs to use the
AsynchronousId int alias for consistency.

In lowering, asynchronous attribute is added on the hlfir.declare of
ASYNCHRONOUS variable, but nothing else is done. This is OK given the
synchronous aspects of flang IO, but it would be safer to treat these
variable as volatile (prevent code motion of related store/loads) since
the asynchronous data change can also be done by C defined user
procedure (see 18.10.4 Asynchronous communication). Flang lowering
anyway does not give enough info for LLVM to do such code motions (the
variables that are passed in a call are not given the noescape
attribute, so LLVM will assume any later opaque call may modify the
related data and would not move load/stores of such variables
before/after calls even if it could from a pure Fortran point of view
without ASYNCHRONOUS).

show more ...


Revision tags: llvmorg-18.1.0-rc1, llvmorg-19-init
# 8f3357b7 02-Jan-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Don't use -1 in I/O API for "default unit" (#76642)

The I/O runtime's API allows -1 to be passed for a unit number in a
READ, WRITE, or PRINT statement, where it gets replaced by 5

[flang][runtime] Don't use -1 in I/O API for "default unit" (#76642)

The I/O runtime's API allows -1 to be passed for a unit number in a
READ, WRITE, or PRINT statement, where it gets replaced by 5 or 6 as
appropriate. This turns out to have been a bad idea, as it prevents the
I/O runtime from detecting and reporting a program's invalid attempt to
use -1 as an I/O unit number. So just pass 5 or 6 as appropriate.

show more ...


Revision tags: llvmorg-17.0.6
# 8cf6e940 21-Nov-2023 kkwli <kkwli@users.noreply.github.com>

[flang] Remove dead code and update test (NFC) (#73004)

OutputUnformattedBlock and InputUnformattedBlock are not used.


Revision tags: llvmorg-17.0.5, llvmorg-17.0.4
# ce6b9b3b 26-Oct-2023 Markus Mützel <markus.muetzel@gmx.de>

[flang][runtime] Avoid dependency on libc++ for `std::__libcpp_verbose_abort`

Changes in libc++ during the development cycle for LLVM 17 lead to the FortranRuntime library depending on libc++.

Tryi

[flang][runtime] Avoid dependency on libc++ for `std::__libcpp_verbose_abort`

Changes in libc++ during the development cycle for LLVM 17 lead to the FortranRuntime library depending on libc++.

Trying to build with Flang 17 that was built with clang++ 17 and libc++ 17 (on MinGW) leads to the following linker error:

ld.lld: error: undefined symbol: std::__1::__libcpp_verbose_abort(char const*, ...)
>>> referenced by libFortranRuntime.a(io-api.cpp.obj):(std::__1::__throw_bad_variant_access[abi:v170000]())
>>> referenced by libFortranRuntime.a(io-stmt.cpp.obj)
>>> referenced by libFortranRuntime.a(unit.cpp.obj)
That might be caused by std::get being called on a std::variant in common::visit.

std::__libcpp_verbose_abort is a weak symbol in libc++ that can be optionally replaced by an alternative definition in user code (see: [1])

Do that to avoid a dependency of the FortranRuntime on libc++.

[1]: https://libcxx.llvm.org/UsingLibcxx.html#overriding-the-default-termination-handler

See also: https://github.com/msys2/MINGW-packages/pull/18002#issuecomment-1694412640

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

show more ...


Revision tags: 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
# 1c35c1a7 06-Jul-2023 Peter Klausler <pklausler@nvidia.com>

[flang] Allow runtime build with AVOID_NATIVE_INT128_T=1

This patch enables the Fortran runtime support library to be
built without native 128-bit integer support in the C++ compiler.

Experimental:

[flang] Allow runtime build with AVOID_NATIVE_INT128_T=1

This patch enables the Fortran runtime support library to be
built without native 128-bit integer support in the C++ compiler.

Experimental: do not merge yet.

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

show more ...


# afdbf1b7 19-Jul-2023 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Detect NEWUNIT= without FILE= or STATUS='SCRATCH'

It is an error to open a new unit with OPEN(NEWUNIT=) and have
neither a file name nor a scratch status. Catch it, and report a
ne

[flang][runtime] Detect NEWUNIT= without FILE= or STATUS='SCRATCH'

It is an error to open a new unit with OPEN(NEWUNIT=) and have
neither a file name nor a scratch status. Catch it, and report a
new error code.

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

show more ...


# c9b31dae 29-Jun-2023 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Allow OPEN(n,ENCODING=) to change the encoding

OPEN statements can be used to change some, but not all, attributes
of units that have already been opened. The I/O runtime library
w

[flang][runtime] Allow OPEN(n,ENCODING=) to change the encoding

OPEN statements can be used to change some, but not all, attributes
of units that have already been opened. The I/O runtime library
wasn't allowing ENCODING= to be changed. Every other Fortran compiler
permits this usage, and it's safe and useful, so allow it.
(Otherwise there's no good way to ensure that the preconnected
unit 6 is in UTF-8 mode.)

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

show more ...


Revision tags: llvmorg-16.0.6
# e468f075 06-Jun-2023 Peter Klausler <pklausler@nvidia.com>

[flang] Set "undefined" NEXTREC=n variable to 0 rather than random garbage

12.10.2.17 defines that a INQUIRE statement's NEXTREC=n output value
for a unit that is not connected for direct access bec

[flang] Set "undefined" NEXTREC=n variable to 0 rather than random garbage

12.10.2.17 defines that a INQUIRE statement's NEXTREC=n output value
for a unit that is not connected for direct access becomes undefined,
but the current I/O runtime can fail in a confusing manner by trying
to return uninitialized stack garbage.

Reported on Slack by Tarun Prabhu as an intermittent failure in
the gfortran regression test inquire_pre.f90.

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

show more ...


Revision tags: llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2
# 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 ...


Revision tags: llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4
# 09b00ab4 10-Mar-2023 Peter Klausler <pklausler@nvidia.com>

[flang] Handle dynamic and remotely scoped non-type-bound UDDTIO subroutines

The present I/O infrastructure for user-defined derived type I/O
subroutines works fine for type-bound I/O generic bindin

[flang] Handle dynamic and remotely scoped non-type-bound UDDTIO subroutines

The present I/O infrastructure for user-defined derived type I/O
subroutines works fine for type-bound I/O generic bindings. It also works
for explicit INTERFACE blocks and GENERIC statements that define
UDDIO subroutines in the same scope as the definition of the derived type,
so long as the specific procedures in those bindings are module procedures
or external procedures.

For non-type-bound UDDTIO specific procedures that are dummy procedures,
thunks of inner procedures, or procedure pointers, or that are defined with
interfaces or GENERIC outside the scope of the definition of the derived
type, a new runtime I/O API is needed so that lowering can generate
a call that supplies the appropriate procedure as well as the defined
type instance.

This patch specifies and implements this new runtime API and provides
utility routines for lowering to use to determine whether it should be
called for any particular OutputItem or InputItem in the parse tree.

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

show more ...


# 79f6b812 08-Mar-2023 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Corrections to formatted child I/O

A handful of I/O statements (OPEN, CLOSE, positioning) are not allowed
on units during child I/O; catch violations and report errors.
Also finesse

[flang][runtime] Corrections to formatted child I/O

A handful of I/O statements (OPEN, CLOSE, positioning) are not allowed
on units during child I/O; catch violations and report errors.
Also finesse error handling during FORMAT runtime parsing of DT
derived type edit descriptors, and ensure that formatted child
I/O is nonadvancing.

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

show more ...


Revision tags: 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, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3
# 27d666b9 24-Aug-2022 V Donaldson <vdonaldson@nvidia.com>

[flang] Noncontiguous formats

Add the remaining pieces to support IO for noncontigous formats.
This is done by passing an array descriptor to IO calls. Scalar
formats continue to pass string and le

[flang] Noncontiguous formats

Add the remaining pieces to support IO for noncontigous formats.
This is done by passing an array descriptor to IO calls. Scalar
formats continue to pass string and length arguments. IO calls
with formats are modified to place the new format descriptor
argument directly after the original string and length arguments.

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


Revision tags: llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# 921316af 26-Jul-2022 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Catch & report attempts at recursive I/O

When an I/O statement contains a function call that attempts
to perform I/O on the same unit, detect the recursive I/O
and terminate with a

[flang][runtime] Catch & report attempts at recursive I/O

When an I/O statement contains a function call that attempts
to perform I/O on the same unit, detect the recursive I/O
and terminate with a useful message rather than deadlocking in
the threading library.

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

show more ...


1234