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