History log of /llvm-project/flang/unittests/Runtime/NumericalFormatTest.cpp (Results 1 – 25 of 28)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6
# c91ba043 06-Dec-2024 Michael Kruse <llvm-project@meinersbur.de>

[Flang][NFC] Split runtime headers in preparation for cross-compilation. (#112188)

Split some headers into headers for public and private declarations in
preparation for #110217. Moving the runtime

[Flang][NFC] Split runtime headers in preparation for cross-compilation. (#112188)

Split some headers into headers for public and private declarations in
preparation for #110217. Moving the runtime-private headers in
runtime-private include directory will occur in #110298.

* Do not use `sizeof(Descriptor)` in the compiler. The size of the
descriptor is target-dependent while `sizeof(Descriptor)` is the size of
the Descriptor for the host platform which might be too small when
cross-compiling to a different platform. Another problem is that the
emitted assembly ((cross-)compiling to the same target) is not identical
between Flang's running on different systems. Moving the declaration of
`class Descriptor` out of the included header will also reduce the
amount of #included sources.

* Do not use `sizeof(ArrayConstructorVector)` and
`alignof(ArrayConstructorVector)` in the compiler. Same reason as with
`Descriptor`.

* Compute the descriptor's extra flags without instantiating a
Descriptor. `Fortran::runtime::Descriptor` is defined in the runtime
source, but not the compiler source.

* Move `InquiryKeywordHashDecode` into runtime-private header. The
function is defined in the runtime sources and trying to call it in the
compiler would lead to a link-error.

* Move allocator-kind magic numbers into common header. They are the
only declarations out of `allocator-registry.h` in the compiler as well.

This does not make Flang cross-compile ready yet, the main goal is to
avoid transitive header dependencies from Flang to clang-rt. There are
more assumptions that host platform is the same as the target platform.

show more ...


Revision tags: llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2
# b1a1d4e0 02-Aug-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Don't emit excess digits for ES0.0E0 or EN0.0E0 (#101238)

Don't emit any digits after the decimal point.


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
# fa465b47 24-Apr-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Improve confusing list-directed REAL(2) output (#89846)

List-directed output editing of REAL values will minimize the number of
digits that are emitted by calculating a decimal val

[flang][runtime] Improve confusing list-directed REAL(2) output (#89846)

List-directed output editing of REAL values will minimize the number of
digits that are emitted by calculating a decimal value that, if read
back in to a REAL variable of the same kind, would compare equal.

This behavior is causing some confusion when applied to list-directed
output of large REAL(2) values. Specifically, the value HUGE(0._2)
(which is 0x7bff in hex) is exactly 65504, but is edited to 65500. by
list-directed output, which selects F0 editing, minimizes the value to
6.55e4, and then formats it without the exponent.

This small patch changes that behavior for cases where the output of
digit-minimized F editing has no digits after the decimal point and
zeroes need to be emitted before it due to the decimal exponent. Digit
minimization is disabled in this case and the exact digits are emitted
instead.

show more ...


Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2
# 7eb5d4fc 18-Mar-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Round hex REAL input correctly with excess digits (#85587)

Excess hexadecimal digits were too significant for rounding purposes,
leading to inappropriate rounding away from zero fo

[flang][runtime] Round hex REAL input correctly with excess digits (#85587)

Excess hexadecimal digits were too significant for rounding purposes,
leading to inappropriate rounding away from zero for some modes.

show more ...


Revision tags: llvmorg-18.1.1
# 4762c655 01-Mar-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Underflow real input to -0. when negative (#82443)

When the result of real input editing underflows to zero, return -0.
when the input field had a minus sign.


Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1
# 033b491c 25-Jan-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Catch error on Ew.0 output editing (#78522)

An Ew.0(Ee) or Ew.0(Ee) output edit descriptor with a scale factor of
zero is an error condition, unless the output edit descriptor was

[flang][runtime] Catch error on Ew.0 output editing (#78522)

An Ew.0(Ee) or Ew.0(Ee) output edit descriptor with a scale factor of
zero is an error condition, unless the output edit descriptor was
originally Gw.0(Ee), list-directed, or just E0/D0 with no .d part.

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

show more ...


Revision tags: llvmorg-19-init
# f45723cd 26-Dec-2023 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Fix RU/RD results when rounding to least nonzero (#75878)

When rounding what otherwise would have been a result that underflowed
to zero up (RU) or down (RD) to the least magnitude

[flang][runtime] Fix RU/RD results when rounding to least nonzero (#75878)

When rounding what otherwise would have been a result that underflowed
to zero up (RU) or down (RD) to the least magnitude nonzero subnormal
number, ensure that the original exponent value doesn't perturb the
result.

show more ...


# 1346037f 26-Dec-2023 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Return +/-HUGE() for some real input roundings (#75525)

The Fortran standard says that overflow input cases in some rounding
modes (RZ, RD, RU) should round to a "representable" nu

[flang][runtime] Return +/-HUGE() for some real input roundings (#75525)

The Fortran standard says that overflow input cases in some rounding
modes (RZ, RD, RU) should round to a "representable" number. Some
Fortran compilers interpret this to mean +/-HUGE(), some as +/-Inf.
Follow the precedent of gfortran and the Intel compilers.

show more ...


# 14e221aa 26-Dec-2023 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Correct EXw.0 output editing (#75121)

A zero 'd' digit count in EX output editing has a meaning that's
distinct from other numeric output editing descriptors, and I missed
this in

[flang][runtime] Correct EXw.0 output editing (#75121)

A zero 'd' digit count in EX output editing has a meaning that's
distinct from other numeric output editing descriptors, and I missed
this in my initial implementation of the feature. d==0 means that the
runtime should emit hexadecimal digits after the (hexa)decimal point
until all of the rest of them would be zero.

show more ...


# ced631e0 11-Dec-2023 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Handle Fw.0 case that needs to round up to 1.0 (#74384)

A tricky case in Fw.d output editing is when the value needs to be
rounded either to a signed zero or away from zero to a po

[flang][runtime] Handle Fw.0 case that needs to round up to 1.0 (#74384)

A tricky case in Fw.d output editing is when the value needs to be
rounded either to a signed zero or away from zero to a power of ten
(1.0, 0.1, &c.). A bug report for LLVM on GitHub (#74274) exposed a bug
in this code in the case of Fw.0 editing where a value just over 0.5 was
rounded incorrectly to 0 rather than 1 when no fractional digits were
requested.

Rework that algorithm a little, ensuring that the initial
binary->decimal conversion produces at least one digit, and coping
correctly with the rounding of an exact 0.5 value for Fw.0 editing
(rounding it to the nearest even decimal, namely 0, following
near-universal compiler-dependent behavior in other Fortrans).

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

show more ...


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3
# ea7e50cd 16-Oct-2023 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Implement EX editing for input & output (#67208)

Support the EX edit descriptor for hexadecimal real formatted output and
hexadecimal real input for all forms of formatted input..

[flang][runtime] Implement EX editing for input & output (#67208)

Support the EX edit descriptor for hexadecimal real formatted output and
hexadecimal real input for all forms of formatted input.. (We're
possibly the first Fortran compiler to support this feature for input
editing; only one other can handle EX output editing.)

As true (not BOZ) hexadecimal floating-point constants are not supported
in Fortran source code, only in formatted input, the implementation
takes place in the I/O editing portion of the runtime, not as new
conversions in the Decimal library.

show more ...


Revision tags: llvmorg-17.0.2
# ffc67bb3 02-Oct-2023 David Spickett <david.spickett@linaro.org>

Revert "[Flang] [FlangRT] Introduce FlangRT project as solution to Flang's runtime LLVM integration"

This reverts commit 6403287eff71a3d6f6c862346d6ed3f0f000eb70.

This is failing on all but 1 of Li

Revert "[Flang] [FlangRT] Introduce FlangRT project as solution to Flang's runtime LLVM integration"

This reverts commit 6403287eff71a3d6f6c862346d6ed3f0f000eb70.

This is failing on all but 1 of Linaro's flang builders.
CMake Error at /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/llvm/flang-rt/unittests/CMakeLists.txt:37 (message):
Target llvm_gtest not found.

show more ...


Revision tags: llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3
# 212beb66 17-Aug-2023 Peter Klausler <pklausler@nvidia.com>

[flang] When formatting integers for Gw.d/Gw.dEe output, only 'w' matters

Leading zeros should appear only for Iw.m output formatting.
Gw, Gw.d, and Gw.dEe output editing all map to Iw with no ".m"

[flang] When formatting integers for Gw.d/Gw.dEe output, only 'w' matters

Leading zeros should appear only for Iw.m output formatting.
Gw, Gw.d, and Gw.dEe output editing all map to Iw with no ".m"
(Fortran 202X 13.7.5.2.2).

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

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, 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, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# df6afee9 22-Jun-2022 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Improve G0 output editing

G0 output editing should never overflow an output field and fill it
with asterisks. It should also never elide the "E" in an exponent
field, even if it ha

[flang][runtime] Improve G0 output editing

G0 output editing should never overflow an output field and fill it
with asterisks. It should also never elide the "E" in an exponent
field, even if it has more than three digits.

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

show more ...


Revision tags: llvmorg-14.0.6, llvmorg-14.0.5
# 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 ...


Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# e6873bfb 06-Apr-2022 Peter Klausler <pklausler@nvidia.com>

[flang][runtime] Don't skip input spaces when they are significant

When formatted input (not list-directed or NAMELIST) is in "BZ" mode,
either because a BZ control edit descriptor appeared in a FOR

[flang][runtime] Don't skip input spaces when they are significant

When formatted input (not list-directed or NAMELIST) is in "BZ" mode,
either because a BZ control edit descriptor appeared in a FORMAT or
BLANK="ZERO" appeared in OPEN or READ, input editing must not skip
over blanks before or within the input field.

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

show more ...


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


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2
# 73b193ae 16-Feb-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Allow more concurrently open NEWUNIT= values, with recycling

Add a header-only implementation of Briggs & Torczon's fast small
integer set data structure to flang/include/flang/Common, and u

[flang] Allow more concurrently open NEWUNIT= values, with recycling

Add a header-only implementation of Briggs & Torczon's fast small
integer set data structure to flang/include/flang/Common, and use
it in the runtime to manage a pool of Fortran unit numbers with
recycling. This replaces the bit set previously used for that
purpose. The set is initialized on demand with the negations of
all the NEWUNIT= unit numbers that can be returned to any kind
of integer variable.

For programs that require more concurrently open NEWUNIT= unit
numbers than the pool can hold, they are now allocated with a
non-recycling counter. This allows as many open units as the
operating system provides.

Many of the top-line comments in flang/unittests/Runtime had the
wrong path name. I noticed this while adding a unit test for the
fast integer set data structure, and cleaned them up.

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

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
# b77fd01a 05-Jan-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Don't blank-fill remaining lines in internal output

Internal writes to character arrays should not blank-fill
records (elements) past the last one that was written to.

Differential Revision

[flang] Don't blank-fill remaining lines in internal output

Internal writes to character arrays should not blank-fill
records (elements) past the last one that was written to.

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

show more ...


Revision tags: llvmorg-13.0.1-rc1
# d02b318a 19-Nov-2021 Peter Klausler <pklausler@nvidia.com>

[flang] Remove typo that affected complex namelist input

A recent patch to real/complex formatted input included what must
have been an editing hiccup: "++ ++p" instead of "++p". This
compiles, and

[flang] Remove typo that affected complex namelist input

A recent patch to real/complex formatted input included what must
have been an editing hiccup: "++ ++p" instead of "++p". This
compiles, and it broke the consumption of the trailing ')' of a
complex value in namelist input by skipping over the character.

Extend existing test to cover this case.

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

show more ...


# da25f968 02-Nov-2021 Peter Klausler <pklausler@nvidia.com>

[flang] Runtime performance improvements to real formatted input

Profiling a basic internal real input read benchmark shows some
hot spots in the code used to prepare input for decimal-to-binary
con

[flang] Runtime performance improvements to real formatted input

Profiling a basic internal real input read benchmark shows some
hot spots in the code used to prepare input for decimal-to-binary
conversion, which is of course where the time should be spent.
The library that implements decimal to/from binary conversions has
been optimized, but not the code in the Fortran runtime that calls it,
and there are some obvious light changes worth making here.

Move some member functions from *.cpp files into the class definitions
of Descriptor and IoStatementState to enable inlining and specialization.

Make GetNextInputBytes() the new basic input API within the
runtime, replacing GetCurrentChar() -- which is rewritten in terms of
GetNextInputBytes -- so that input routines can have the
ability to acquire more than one input character at a time
and amortize overhead.

These changes speed up the time to read 1M random reals
using internal I/O from a character array from 1.29s to 0.54s
on my machine, which on par with Intel Fortran and much faster than
GNU Fortran.

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

show more ...


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


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


12