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