History log of /llvm-project/flang/runtime/edit-output.cpp (Results 26 – 50 of 60)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5
# db52dda8 08-Jun-2022 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Detect overflow of fixed-sized exponent output field

When Ew.dEe or Gw.dEe output has an exponent requiring more than 'e'
digits, the whole output field must overflow to asterisks.

[flang][runtime] Detect overflow of fixed-sized exponent output field

When Ew.dEe or Gw.dEe output has an exponent requiring more than 'e'
digits, the whole output field must overflow to asterisks. The runtime
was detecting short fields and padding them with zeroes, but not
overflow.

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

show more ...


# 3f3edbe5 08-Jun-2022 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Don't emit any leading blanks for G0/E0 output editing

There were cases where E0.d output editing (or G0.d editing that is converted
to E0.d) would emit one or more leading blank ch

[flang][runtime] Don't emit any leading blanks for G0/E0 output editing

There were cases where E0.d output editing (or G0.d editing that is converted
to E0.d) would emit one or more leading blank characters; fix them.

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

show more ...


# dfcccc6d 01-Jun-2022 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Fix edge case discrepancies with EN output editing

The "engineering" ENw.d output editing descriptor has some difficult
edge case behavior for values that might format into a bunch

[flang][runtime] Fix edge case discrepancies with EN output editing

The "engineering" ENw.d output editing descriptor has some difficult
edge case behavior for values that might format into a bunch of 9's
or round up to a 1 for a given scale factor. Fix the algorithm,
and add tests to protect against regressions.

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

show more ...


# da63fee0 28-May-2022 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Allow extra character for E0.0 output editing

When the digit count ('d') is zero in E0 editing, allow for one more
output character; otherwise, any - or + sign in the output causes

[flang][runtime] Allow extra character for E0.0 output editing

When the digit count ('d') is zero in E0 editing, allow for one more
output character; otherwise, any - or + sign in the output causes
an output field overflow.

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

show more ...


# 604016db 28-May-2022 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Fix bug with extra leading zero in octal output

Octal (O) output editing often emits an extra leading 0 digit
due to the total digit count being off by one since word sizes
aren't m

[flang][runtime] Fix bug with extra leading zero in octal output

Octal (O) output editing often emits an extra leading 0 digit
due to the total digit count being off by one since word sizes
aren't multiples of three bits.

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

show more ...


Revision tags: llvmorg-14.0.4, llvmorg-14.0.3
# 28b5e99a 28-Apr-2022 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] (G0) for CHARACTER means (A), not (A0)

I'm emitting zero characters for (G0) formatting of CHARACTER values
instead of using their lengths to determine the output field width.

Diff

[flang][runtime] (G0) for CHARACTER means (A), not (A0)

I'm emitting zero characters for (G0) formatting of CHARACTER values
instead of using their lengths to determine the output field width.

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

show more ...


# 53f775bb 27-Apr-2022 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Support B/O/Z editing of CHARACTER

This is a common extension, though semantics differ across
compilers. I've chosen to interpret the CHARACTER data
as if it were an arbitrary-prec

[flang][runtime] Support B/O/Z editing of CHARACTER

This is a common extension, though semantics differ across
compilers. I've chosen to interpret the CHARACTER data
as if it were an arbitrary-precision integer value and
format or read it as such. This matches Intel's compilers
and nvfortran. (GNU Fortran can't handle lengths > 1 and XLF
seems to get the enddianness wrong.)

This patch generalizes the previous implementations of
B/O/Z input and output so that they'll work for arbitrary data
in memory, and then uses them for all B/O/Z input/output,
including (now) CHARACTER.

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

show more ...


Revision tags: llvmorg-14.0.2
# c02abb68 22-Apr-2022 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Enforce some limits on kP scale factors

Ew.d and Dw.d output edit descriptors should respect limitations from
the standard on the value of a kP scale factor with respect to the
digi

[flang][runtime] Enforce some limits on kP scale factors

Ew.d and Dw.d output edit descriptors should respect limitations from
the standard on the value of a kP scale factor with respect to the
digit count (d), at least for values of k other than zero.

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

show more ...


Revision tags: llvmorg-14.0.1
# 724709e0 04-Apr-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Make F0.1 output editing of zero edge case consistent

The statement
PRINT '(2F0.1)', 0.0, 0.5
should emit consistent ".0 .5" output, not "0.0 .5".

Differential Revision: https://reviews.l

[flang] Make F0.1 output editing of zero edge case consistent

The statement
PRINT '(2F0.1)', 0.0, 0.5
should emit consistent ".0 .5" output, not "0.0 .5".

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

show more ...


# 664c111c 01-Apr-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Always encode multi-byte output in UTF-8

A recent change to implement UTF-8 encoding should have
made the encoding conditional only for CHARACTER(KIND=1)
to enable UTF-8 output vs. Latin-1 o

[flang] Always encode multi-byte output in UTF-8

A recent change to implement UTF-8 encoding should have
made the encoding conditional only for CHARACTER(KIND=1)
to enable UTF-8 output vs. Latin-1 or whatever. UTF-8 output
of wider CHARACTER kinds should not be conditional (until we choose
to support UCS-16, maybe). So wider CHARACTER kinds are being
emitted with extra zero bytes; this patch fixes them.

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

show more ...


# 88d4b85f 31-Mar-2022 Jean Perier <jperier@nvidia.com>

[flang] Allow user to recover from bad edit descriptor with INTEGER

Runtime was crashing when an INTEGER passed in formatted output with
a bad edit descriptor even when the user did provide IOSTAT.

[flang] Allow user to recover from bad edit descriptor with INTEGER

Runtime was crashing when an INTEGER passed in formatted output with
a bad edit descriptor even when the user did provide IOSTAT. Flang
is already signaling an error when facing similar error with other
types. Do the same with INTEGERs.

The input case is already signaling an error in the related input error
case.

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

show more ...


# df209b80 23-Mar-2022 Peter Steinfeld <psteinfeld@nvidia.com>

[flang] Make not yet implemented messages more consistent

To make it easier to find things that are not yet implemented, I'm changing the
messages that appear in the compiler's output to all have th

[flang] Make not yet implemented messages more consistent

To make it easier to find things that are not yet implemented, I'm changing the
messages that appear in the compiler's output to all have the string "not yet
implemented:".

These changes apply to files in the front end. I have another set of changes
to files in the lowering code.

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

show more ...


# bafbae23 16-Mar-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Initial UTF-8 support in runtime I/O

Implements UTF-8 encoding and decoding for external units
with OPEN(ENCODING='UTF-8'). This encoding applies to default
CHARACTER values that are not 7-

[flang] Initial UTF-8 support in runtime I/O

Implements UTF-8 encoding and decoding for external units
with OPEN(ENCODING='UTF-8'). This encoding applies to default
CHARACTER values that are not 7-bit ASCII as well as to
the wide CHARACTER kinds 2 and 4. Basic testing is in place
via direct calls to the runtime I/O APIs, but serious checkout
awaits lowering support of the wide CHARACTER kinds.

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

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2
# 3a96446d 17-Feb-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Honor RECL= in list-directed/namelist output

Advancement to new output lines was taking fixed-sized direct-access
and internal character array element lengths into account, but not
RECL= set

[flang] Honor RECL= in list-directed/namelist output

Advancement to new output lines was taking fixed-sized direct-access
and internal character array element lengths into account, but not
RECL= settings from OPEN statements.

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

show more ...


Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# d1b09ade 10-Nov-2021 Peter Klausler <pklausler@nvidia.com>

[flang] Fix rounding edge case in F output editing

When an Fw.d output edit descriptor has a "d" value exactly
equal to the number of zeroes after the decimal point for a value
(e.g., 0.07 with F5.1

[flang] Fix rounding edge case in F output editing

When an Fw.d output edit descriptor has a "d" value exactly
equal to the number of zeroes after the decimal point for a value
(e.g., 0.07 with F5.1), the Fw.d output editing code needs to
do the rounding itself to either 0.0 or 0.1 after performing
a conversion without rounding (to avoid 0.04999 rounding up twice).

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

show more ...


# b83242e2 21-Oct-2021 peter klausler <pklausler@nvidia.com>

[flang] Support legacy usage of 'A' edit descriptors for integer & real

The 'A' edit descriptor once served as a form of raw I/O of bytes
to/from variables that weren't of type CHARACTER (which itse

[flang] Support legacy usage of 'A' edit descriptors for integer & real

The 'A' edit descriptor once served as a form of raw I/O of bytes
to/from variables that weren't of type CHARACTER (which itself
didn't exist until F'77). This usage was especially common for
output of numeric variables that had been initialized with Hollerith.

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

show more ...


# c5a5517b 13-Oct-2021 peter klausler <pklausler@nvidia.com>

[flang] Fixing Windows build (take 3)

Add explicit casts to replace implicit conversions and
recently deleted assignment operators from uint128.h
used in runtime/edit-output.cpp.


# f65f830e 11-Oct-2021 peter klausler <pklausler@nvidia.com>

[flang] runtime: fix output B/O/Z editing of "negative" values

B/O/Z integer output editing must not reflect any sign extension
of scalar output values. Add more size-dependent OutputInteger
I/O AP

[flang] runtime: fix output B/O/Z editing of "negative" values

B/O/Z integer output editing must not reflect any sign extension
of scalar output values. Add more size-dependent OutputInteger
I/O APIs and kind instantiations of EditIntegerOutput.

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

show more ...


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3
# 651f58bf 02-Sep-2021 Diana Picus <diana.picus@linaro.org>

[flang] Remove *- C++ -* incantation from runtime .cpp files. NFC

We should only need to spell the language out in .h files.

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


Revision tags: llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1
# 4876520e 02-Aug-2021 peter klausler <pklausler@nvidia.com>

[flang] runtime: For Fw.d formatting, don't oscillate forever

The algorithm for Fw.d output will drive binary to decimal conversion for
an initial fixed number of digits, then adjust that number bas

[flang] runtime: For Fw.d formatting, don't oscillate forever

The algorithm for Fw.d output will drive binary to decimal conversion for
an initial fixed number of digits, then adjust that number based on the
result's exposent. For value close to a power of ten, this adjustment
process wouldn't terminate; e.g., formatting 9.999 as F10.2 would start
with 1e2, boost the digits to 2, get 9.99e1, decrease the digits, and loop.
Solve by refusing to boost the digits a second time.

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

show more ...


Revision tags: llvmorg-14-init
# 4d42e16e 22-Jul-2021 peter klausler <pklausler@nvidia.com>

[flang] runtime: fix problems with I/O around EOF & delimited characters

When a WRITE overwrites an endfile record, we need to forget
that there was an endfile record. When doing a BACKSPACE
after

[flang] runtime: fix problems with I/O around EOF & delimited characters

When a WRITE overwrites an endfile record, we need to forget
that there was an endfile record. When doing a BACKSPACE
after an explicit ENDFILE statement, the position afterwards
must be upon the endfile record.

Attempts to join list-directed delimited character input across
record boundaries was due to a bad reading of the standard
and has been deleted, now that the requirements are better understood.
This problem would cause a read attempt past EOF if a delimited
character input value was at the end of a record.

It turns out that delimited list-directed (and NAMELIST) character
output is required to emit contiguous doubled instances of the
delimiter character when it appears in the output value. When
fixed-size records are being emitted, as is the case with internal
output, this is not possible when the problematic character falls
on the last position of a record. No two other Fortran compilers
do the same thing in this situation so there is no good precedent
to follow.

Because it seems least wrong, with this patch we now emit one copy
of the delimiter as the last character of the current record and
another as the first character of the next record. (The
second-least-wrong alternative might be to flag a runtime error,
but that seems harsh since it's not an explicit error in the standard,
and the output may not have to be usable later as input anyway.)
Consequently, the output is not suitable for use as list-directed or
NAMELIST input.

If a later standard were to clarify this case, this behavior will of
course change as needed to conform.

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

show more ...


Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1
# 6a1c3efa 05-May-2021 peter klausler <pklausler@nvidia.com>

[flang] Implement NAMELIST I/O in the runtime

Add InputNamelist and OutputNamelist as I/O data transfer APIs
to be used with internal & external list-directed I/O; delete the
needless original namel

[flang] Implement NAMELIST I/O in the runtime

Add InputNamelist and OutputNamelist as I/O data transfer APIs
to be used with internal & external list-directed I/O; delete the
needless original namelist-specific Begin... calls.
Implement NAMELIST output and input; add basic tests.

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

show more ...


Revision tags: 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, 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
# b1afbceb 15-Dec-2020 peter klausler <pklausler@nvidia.com>

[flang] Minor fix to list-directed REAL output editing

Always emit the letter 'E' in list-directed REAL output;
the library was omitting it for exponents greater than 99,
as should be done for E and

[flang] Minor fix to list-directed REAL output editing

Always emit the letter 'E' in list-directed REAL output;
the library was omitting it for exponents greater than 99,
as should be done for E and D formatting of large exponents
without an Ed exponent digit count.

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

show more ...


Revision tags: llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6
# d56fdc8e 02-Oct-2020 peter klausler <pklausler@nvidia.com>

[flang][msvc] Avoid dependence on long double

MSVC does not support a distinct 80-bit extended precision
"long double" type. Rework the I/O runtime to avoid using
native C/C++ type names. Centrali

[flang][msvc] Avoid dependence on long double

MSVC does not support a distinct 80-bit extended precision
"long double" type. Rework the I/O runtime to avoid using
native C/C++ type names. Centralize the mappings between
the KIND= type parameters of REAL and their binary precisions
in the common real.h header file, and use KIND type parameter
values rather than binary precisions for clarity where
appropriate.

This patch, if successful, should obviate the need for
Differential review D88511.

(This patch anticipates a successful review of D88688, which
fixes the function that maps each kind of real to its maximum
number of significant decimal digits.)

Differential revision: https://reviews.llvm.org/D88752

show more ...


# 567462b4 30-Sep-2020 peter klausler <pklausler@nvidia.com>

[flang] Correct kP scaling on F output

The sign of the scaling factor was misinterpreted for output
as meaning what it does for input. To be correct, they
should cancel each other out.

print '(1P,

[flang] Correct kP scaling on F output

The sign of the scaling factor was misinterpreted for output
as meaning what it does for input. To be correct, they
should cancel each other out.

print '(1P,F4.3)', 1. ! printed 0.1 but should print 10.0

Differential revision: https://reviews.llvm.org/D88610

show more ...


123