History log of /llvm-project/flang/lib/Decimal/big-radix-floating-point.h (Results 1 – 17 of 17)
Revision Date Author Comments
# 1444e5ac 22-Apr-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang] Complete implementation of OUT_OF_RANGE() (#89334)

The intrinsic function OUT_OF_RANGE() lacks support in lowering and the
runtime. This patch obviates a need for any such support by implem

[flang] Complete implementation of OUT_OF_RANGE() (#89334)

The intrinsic function OUT_OF_RANGE() lacks support in lowering and the
runtime. This patch obviates a need for any such support by implementing
OUT_OF_RANGE() via rewriting in semantics. This rewriting of
OUT_OF_RANGE() calls replaces the existing code that folds
OUT_OF_RANGE() calls with constant arguments.

Some changes and fixes were necessary outside of OUT_OF_RANGE()'s
folding code (now rewriting code), whose testing exposed some other
issues worth fixing.

- The common::RealDetails<> template class was recoded in terms of a new
base class with a constexpr constructor, so that the the characteristics
of the various REAL kinds could be queried dynamically as well. This
affected some client usage.
- There were bugs in the code that folds TRANSFER() when the type of X
or MOLD was REAL(10) -- this is a type that occupies 16 bytes per
element in execution memory but only 10 bytes (was 12) in the data of
std::vector<Scalar<>> in a Constant<>.
- Folds of REAL->REAL conversions weren't preserving infinities.

show more ...


# b329da89 05-Apr-2024 Slava Zakharin <szakharin@nvidia.com>

[flang][runtime] Support for offload build of FortranDecimal. (#87653)


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


# fc04472a 02-Sep-2023 Fangrui Song <i@maskray.me>

[flang] Fix duplicate word typos; NFC

Those fixes were taken from https://reviews.llvm.org/D137338


# 0e05ab67 26-May-2023 Peter Klausler <pklausler@nvidia.com>

[flang] Fix interpretations of x87 80-bit Inf/NaN

Current implementations of x87 80-bit extended precision floating
point interpret 7FFF8000000000000000 as +Inf, not a Nan. The explicit
MSB in the

[flang] Fix interpretations of x87 80-bit Inf/NaN

Current implementations of x87 80-bit extended precision floating
point interpret 7FFF8000000000000000 as +Inf, not a Nan. The explicit
MSB in the significand must be set for an infinity.

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

show more ...


# e593940b 28-Mar-2023 Peter Klausler <pklausler@nvidia.com>

[flang] Fine-tune NAN formatted input editing

Per Fortran 2018, "NAN" and "NAN()" are to be translated into quiet
NaNs, and the other forms are implementation-dependent; I've made
them quiet NaNs t

[flang] Fine-tune NAN formatted input editing

Per Fortran 2018, "NAN" and "NAN()" are to be translated into quiet
NaNs, and the other forms are implementation-dependent; I've made
them quiet NaNs too. Also process signs on input NaNs, which seems
wrong but other compilers all do it, and fix some misleading template
argument names noticed along the way.

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

show more ...


# 042c964d 13-Jan-2023 Peter Klausler <pklausler@nvidia.com>

[flang] Fix defined I/O semantics crash & missing errors that exposed it

Semantics crashes when emitting runtime derived type information tables
for a type that has user-defined I/O procedures decla

[flang] Fix defined I/O semantics crash & missing errors that exposed it

Semantics crashes when emitting runtime derived type information tables
for a type that has user-defined I/O procedures declared outside the
type with explicit INTERFACE blocks (as opposed to a GENERIC binding
within the type). This is due to the runtime table constructor
adding a table entry for each specific procedure of any explicit interface
of the right kind (e.g., READ(UNFORMATTED)) that it found, rather than
just the ones that pertain to the derived type in question. But
semantics also wasn't checking such interfaces for distinguishable
specific procedures, either.

Clean these up, improve the spelling of defined I/O procedure kinds
in error messages ("read(formatted)" rather than "READFORMATTED"),
and make error messages stemming from macro expansions only have
one "error:" prefix on the original message so that a new test
would work.

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

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


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

[flang] Readability improvement in binary->decimal conversion

Tweak binary->decimal conversions to avoid an integer multiplication
in a hot loop to improve readability and get a minor (~5%) speed-up

[flang] Readability improvement in binary->decimal conversion

Tweak binary->decimal conversions to avoid an integer multiplication
in a hot loop to improve readability and get a minor (~5%) speed-up.
Use native integer division by constants for more readability, too,
since current build compilers seem to optimize it correctly now.
Delete the now needless temporary work-around facility in
Common/unsigned-const-division.h.

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

show more ...


# 49bbb8b6 03-Aug-2020 peter klausler <pklausler@nvidia.com>

Remove unneeded RoundDefault enumerator, and fix spelling in comments


# ce6f0303 14-Jul-2020 peter klausler <pklausler@nvidia.com>

[flang] Tuning up binary->decimal conversion

Use short division of big-radix values by powers of two when
converting values with negative unbiased exponents rather than
multiplication by smaller pow

[flang] Tuning up binary->decimal conversion

Use short division of big-radix values by powers of two when
converting values with negative unbiased exponents rather than
multiplication by smaller powers of five; this reduces the overall
outer iteration count. This change is a win across the entire range
of inputs.

Reviewed By: tskeith

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

show more ...


# 7cccd49a 02-Jul-2020 peter klausler <pklausler@nvidia.com>

[flang] Clean up binary dependences of runtime libraries

There were dependences upon LLVM libraries in the Fortran
runtime support library binaries due to some indirect #includes
of llvm/Support/raw

[flang] Clean up binary dependences of runtime libraries

There were dependences upon LLVM libraries in the Fortran
runtime support library binaries due to some indirect #includes
of llvm/Support/raw_ostream.h, which caused some kind of internal
ABI version consistency checking to get pulled in. Fixed by
cleaning up some includes.

Reviewed By: tskeith, PeteSteinfeld, sscalpone

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

show more ...


# 38674030 08-Jun-2020 Valentin Clement <clementval@gmail.com>

Apply fix from D81179 only from GCC < 8

Summary: Apply workaround done in D81179 only for GCC < 8. As @klausler mentioned in D81179 we want to avoid additional checks for other compilers that do not

Apply fix from D81179 only from GCC < 8

Summary: Apply workaround done in D81179 only for GCC < 8. As @klausler mentioned in D81179 we want to avoid additional checks for other compilers that do not need them.

Reviewers: DavidTruby, klausler, jdoerfert, sscalpone

Reviewed By: klausler, sscalpone

Subscribers: llvm-commits, tskeith, isuruf, klausler

Tags: #flang, #llvm

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

show more ...


# 3d9bb031 04-Jun-2020 Valentin Clement <clementval@gmail.com>

[flang] avoid GCC < 8 compiler failure after D80794

Summary:
Patch D80794 remove the custom flags for release build for flang.
This leads to build failure with GCC < 8. This patch add upperbound che

[flang] avoid GCC < 8 compiler failure after D80794

Summary:
Patch D80794 remove the custom flags for release build for flang.
This leads to build failure with GCC < 8. This patch add upperbound check
in order to avoid the -Werror=array-bounds to trigger a build failure.

```
/home/4vn/versioning/llvm-project/flang/lib/Decimal/big-radix-floating-point.h:183:29: error: array subscript is above array bounds [-Werror=array-bounds]
digit_[j] = digit_[j + remove];
~~~~~~^
/home/4vn/versioning/llvm-project/flang/lib/Decimal/big-radix-floating-point.h:183:29: error: array subscript is above array bounds [-Werror=array-bounds]
digit_[j] = digit_[j + remove];
~~~~~~^
/home/4vn/versioning/llvm-project/flang/lib/Decimal/big-radix-floating-point.h:183:29: error: array subscript is above array bounds [-Werror=array-bounds]
digit_[j] = digit_[j + remove];
~~~~~~^
/home/4vn/versioning/llvm-project/flang/lib/Decimal/big-radix-floating-point.h:183:29: error: array subscript is above array bounds [-Werror=array-bounds]
digit_[j] = digit_[j + remove];
~~~~~~^
/home/4vn/versioning/llvm-project/flang/lib/Decimal/big-radix-floating-point.h:183:29: error: array subscript is above array bounds [-Werror=array-bounds]
digit_[j] = digit_[j + remove];
```

```
/home/4vn/versioning/llvm-project/flang/include/flang/Evaluate/integer.h:809:28: error: array subscript is above array bounds [-Werror=array-bounds]
xy += product[to];
~~~~~~~^
/home/4vn/versioning/llvm-project/flang/include/flang/Evaluate/integer.h:810:22: error: array subscript is above array bounds [-Werror=array-bounds]
product[to] = xy & partMask;
~~~~~~~^
/home/4vn/versioning/llvm-project/flang/include/flang/Evaluate/integer.h:809:28: error: array subscript is above array bounds [-Werror=array-bounds]
xy += product[to];
~~~~~~~^
```

Reviewers: DavidTruby, sscalpone, jdoerfert

Reviewed By: DavidTruby

Subscribers: llvm-commits

Tags: #llvm, #flang

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

show more ...


# 6fec2c44 04-May-2020 peter klausler <pklausler@nvidia.com>

[flang] Fix x87 binary->decimal

Summary:
Fix decimal formatting of 80-bit x87 values; the calculation ofnearest neighbor values failed to account for the explicitmost significant bit in that format.

[flang] Fix x87 binary->decimal

Summary:
Fix decimal formatting of 80-bit x87 values; the calculation ofnearest neighbor values failed to account for the explicitmost significant bit in that format.

Replace MultiplyByRounded with MultiplyBy in binary->decimal conversions,
since rounding won't happen and the name was misleading; then remove
dead code, and migrate LoseLeastSignificantDigit() from one source file
to another where it's still needed.

Reviewers: tskeith, sscalpone, jdoerfert, DavidTruby

Reviewed By: tskeith

Subscribers: llvm-commits, flang-commits

Tags: #flang, #llvm

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

show more ...


# 1f879005 29-Mar-2020 Tim Keith <tkeith@nvidia.com>

[flang] Reformat with latest clang-format and .clang-format

Original-commit: flang-compiler/f18@9fe84f45d7fd685051004678d6b5775dcc4c6f8f
Reviewed-on: https://github.com/flang-compiler/f18/pull/1094


# 64ab3302 25-Feb-2020 CarolineConcatto <51754594+CarolineConcatto@users.noreply.github.com>

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-b

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Original-commit: flang-compiler/f18@d2eb7a1c443d1539ef12b6f027074a0eb15b1ea0
Reviewed-on: https://github.com/flang-compiler/f18/pull/980

show more ...