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