[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #10 from Thomas Henlich --- (In reply to Jerry DeLisle from comment #5) > Author: jvdelisle > Date: Thu Nov 28 18:33:20 2019 > New Revision: 278817 > > URL: https://gcc.gnu.org/viewcvs?rev=278817&root=gcc&view=rev > Log: > PR fortran/90374 > * io.c (check_format): Allow zero width expoenent with e0. > > * io/format.c (parse_format_list): Relax format checking to allow > e0 exponent specifier. > > * gfortran.dg/fmt_zero_width.f90: Update test. > > Modified: > trunk/gcc/fortran/ChangeLog > trunk/gcc/fortran/io.c > trunk/gcc/testsuite/ChangeLog > trunk/gcc/testsuite/gfortran.dg/fmt_zero_width.f90 > trunk/libgfortran/ChangeLog > trunk/libgfortran/io/format.c > trunk/libgfortran/io/write_float.def fmt_zero_width.f90: .. write (aresult,fmt="(E0.10e0)") rn if (aresult /= "0.313928E-02") stop 39 Shouldn't that be (according to Fortran 2018): if (aresult /= "0.313928E-2") stop 39 13.7.2.3.3 E and D editing ... If e is positive the exponent part contains e digits, otherwise it contains the minimum number of digits required to represent the exponent value. ...
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #12 from Thomas Henlich --- The following: program test write(*, "(e0.10e2)") 0.00314_4 end results in error: At line 2 of file test-f2018.f90 (unit = 6, file = 'stdout') Fortran runtime error: Period required in format (e0.10e2) ^
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #13 from Thomas Henlich --- Just a minor issue: I think that the sense of the message arguments in calls to gfc_notify_std() should be inverted - they should describe the feature as supported in the correct standard, and not as an error message. For example: gfc_notify_std (GFC_STD_F2018, "positive width required at %L", &format_locus) should read gfc_notify_std (GFC_STD_F2018, "zero width at %L", &format_locus) It just seems counter-intuitive to read a message like: gfortran -std=f2008 -o test-f2018.exe test-f2018.f90 2 | write(*, "(e0.10e2)") 0.00314_4 |1 Error: Fortran 2018: positive width required at (1) because the user is trying to access a feature (zero width) of Fortran 2018, but that fails. The current message implies that "Fortran 2018 requires a positive width" which is exactly the opposite, this is confusing.
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #14 from Thomas Henlich --- (In reply to Thomas Henlich from comment #13) As reference, see this comment: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51081#c0
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #15 from Thomas Henlich --- (In reply to Thomas Henlich from comment #13) As reference, see this comment: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51081#c0
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #18 from Thomas Henlich --- (In reply to Thomas Henlich from comment #13) > For example: > > gfc_notify_std (GFC_STD_F2018, "positive width required at %L", > &format_locus) > > should read > gfc_notify_std (GFC_STD_F2018, "zero width at %L", &format_locus) Even so, "zero width" is not the best choice of words, "E0.d editing" or "E0 editing" would be more appropriate; or "% in format at %L" to keep it consisten with other uses.
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #23 from Thomas Henlich --- (In reply to Jerry DeLisle from comment #21) > Author: jvdelisle > Date: Thu Jan 2 00:57:31 2020 > New Revision: 279828 > > URL: https://gcc.gnu.org/viewcvs?rev=279828&root=gcc&view=rev Jerry, please note that the standard requires that the minimum exponent width is only selected in case of Ew.dE0 editing (including E0.dE0), but not for E0.d editing in general. Your latest patch changes this behaviour. See Table 13.1: E and D exponent forms Edit Absolute Value Form of Descriptorof Exponent Exponent (1) Ew.d |exp| ≤ 99 E±z1z2 or ±0z1z2 99 < |exp| ≤ 999 ±z1z2z3 Ew.d Ee with e > 0|exp| ≤ 10^e − 1 E±z1z2 . . . ze Ew.d E0 any E±z1z2 . . . zs Dw.d |exp| ≤ 99 D±z1z2 or E±z1z2 or ±0z1z2 99 < |exp| ≤ 999 ±z1z2z3 (1) where each z is a digit, and s is the minimum number of digits required to represent the exponent.
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #24 from Thomas Henlich ---
There is another issue with E0.d editing, concerning the case |exp| ≥ 1000 with
extended and quad precision.
In addition to tables 13.1 ... 13.3, the standard says:
13.7.2 Numeric editing
13.7.2.1 General rules
...
(5) On output, if an exponent exceeds its specified or implied width using the
E, EN, ES, EX, D, or G edit descriptor, or the number of characters produced
exceeds the field width, the processor shall fill the entire field of width w
with asterisks. However, the processor shall not produce asterisks if the field
width is not exceeded when optional characters are omitted.
(6) On output, with I, B, O, Z, D, E, EN, ES, EX, F, and G editing, the
specified value of the field width w may be zero. In such cases, the processor
selects the smallest positive actual field width that does not result in a
field filled with asterisks. The specified value of w shall not be zero on
input.
Example:
Should the following code
write(*, "(e0.10)") 1e1234_10
result in
a) a field filled with asterisks because 13.7.2.1(5) applies, and if so, how
many?
b) the same output as E0.10E4 editing ("0.10E+1234") because
13.7.2.1(6) applies
In my opinion, it should be a), with a field width corresponding to the width
of the field corresponding to the smallest width required for the mantissa plus
4 for the implied exponent width.
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #25 from Thomas Henlich ---
On second thoughts, I change my mind to:
c) the same output as G0.10 editing ("0.10E+1235") because there is no
need to do it differently for E editing.
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #26 from Thomas Henlich --- I must admit that the following F2018 clause invalidates my previous comment, because it applies to G editing specifically (but not to E editing) 13.7.5.2.2 Generalized real and complex editing ... 3 When used to specify the output of real or complex data ..., the G0 and G0.d edit descriptors follow the rules for the Gw.dEe edit descriptor, except that any leading or trailing blanks are removed. Reasonable processor-dependent values of w, d (if not specified), and e are used with each output value.
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #30 from Thomas Henlich ---
(In reply to Jerry DeLisle from comment #29)
> I think this last patch above fixes the last adjustment needed. I could be
> wrong I suppose. Is this ready to close?
Jerry, thanks for the good work so far!
But I found this issue:
program test
write(*, "(g0.2)") 0.1e-9
write(*, "(g8.2)") 0.1e-9
write(*, "(g0.2)") 0.1e123_10
write(*, "(g8.2)") 0.1e123_10
end
Output from GCC 9.2.0:
0.10E-09
0.10E-09
0.10E+0123
0.10+123
I think this is correct, according to the table from the standard F2008/F2018
(see my comment #23 above)
Now after these patches, I get something different:
0.10E-9
0.10E-09
0.10E+123
0.10+123
With G0.d" (and starting with F2018 with E0.d, D0.d, EN0.d, ES0.d etc.
likewise), the processor is only allowed to remove leading/trailing spaces
("select ... actual field width"). It is not allowed to change the exponent
format in this case. This would only be the case if E...e0" editing is
explicitly requested.
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #31 from Thomas Henlich ---
Jerry, I reviewed some of the code in write_float.def:
478 /* Calculate the format of the exponent field. */
479 if (expchar && !(dtp->u.p.g0_no_blanks && e == 0))
480 {
481 edigits = 1;
482 for (i = abs (e); i >= 10; i /= 10)
483 edigits++;
484
...
499 /* Zero width specified, no leading zeros in exponent */
500 if (e > 999 || e < -999)
501 edigits = 6;
502 else if (e > 99 || e < -99)
503 edigits = 5;
504 else if (e > 9 || e < -9)
505 edigits = 4;
506 else
507 edigits = 3;
To me this seems somewhat redundant.
Wouldn't the following be somewhat shorter, with the same result?
500 edigits += 2;
[Bug libfortran/93550] New: Implement control of leading zero in formatted numeric output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93550 Bug ID: 93550 Summary: Implement control of leading zero in formatted numeric output Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich+gccbug at gmail dot com Target Milestone: --- In 2018, J3 Fortran Standards Committee agreed to add "leading zero format control" to its work list for Fortran 202x. While not (yet) part of the Fortran standard, it might make sense to implement (as an experimental GNU extension) or at least prepare for this upcoming change in order to clean up the library code, thus removing all hard-coded assumptions regarding leading zero. https://j3-fortran.org/doc/year/18/18-268.txt: When using F format to output a value less than 1, the standard allows the implementation to choose whether to include a zero before the decimal symbol. 13.7.2.3.2 (F format) paragraph 11 says (in part): "Leading zeros are not permitted except for an optional zero immediately to the left of the decimal symbol if the magnitude of the value in the output field is less than one. The optional zero shall appear if there would otherwise be no digits in the output field." Similarly for E and D formats, when the scale factor is zero, 13.7.2.3.2p11 says: "Leading zeros are not permitted except for an optional zero immediately to the left of the decimal symbol if the magnitude of the value in the output field is less than one. The optional zero shall appear if there would otherwise be no digits in the output field." EN, ES and EX formats do not have this option. Some implementations always provide the leading zeros, some do not, and this inconsistency results in user complaints, especially when test programs produce different results across different implementations. The inconsistency also occurs for G format when the value is in a certain range, since E and F formatting is used. Unlike the optional sign before a positive value, there is no user control over the optional zero. Use Cases - Many users have complained over the years that this inconsistency makes it difficult to automatically validate results across different implementations and, in some cases where the leading zero is omitted, makes the output from a Fortran application unusable by applications written in other languages. Requirements - Add control edit descriptors, analogous to the SS, SP and S edit descriptors, allowing the programmer to specify whether a leading zero is to appear in output for the F, E, D and G formats in the cases where it is currently optional. The requirement of the leading zero when otherwise no digits would appear is to remain. As with the existing S control descriptor, one of the new descriptors selects the implementation-defined behavior, which remains the default. - Continuing the analogy with SS, SP and S, and the SIGN= OPEN/INQUIRE specifier, add a new specifier to OPEN and INQUIRE to allow specification or inquiry of the current mode. Like SIGN=, this is to be a "changeable mode" (12.5.2p1). List-directed and namelist- directed output are to use the current "leading zero" mode. https://j3-fortran.org/doc/year/19/19-156r1.txt: Requirements - Add control edit descriptors, analogous to the SS, SP and S edit descriptors, allowing the programmer to specify whether a leading zero is to appear in output for the F, E, D and G formats in the cases where it is currently optional. The requirement of the leading zero when otherwise no digits would appear is to remain. As with the existing S control descriptor, one of the new descriptors selects the implementation-defined behavior, which remains the default. - Continuing the analogy with SS, SP and S, and the SIGN= OPEN/INQUIRE specifier, add a new specifier to OPEN and INQUIRE to allow specification or inquiry of the current mode. Like SIGN=, this is to be a "changeable mode" (12.5.2p1). List-directed and namelist- directed output are to use the current "leading zero" mode. Specification - 1. Add the following control edit descriptors: LZS, LZP, LZ. The LZS, LZP, and LZ edit descriptors temporarily change (12.5.2) the leading zero mode for the connection. The edit descriptors LZS, LZP, and LZ set the leading zero mode corresponding to the LEADING_ZERO= specifier values SUPPRESS, PRINT, and PROCESSOR_DEFINED, respectively. The leading zero mode controls optional leading zero characters in numeric output fields. When the leading zero mode is PRINT, the processor shall produce a leading zero in any position that normally contains an optional leading zero. When the leading zero mode is SUPP
[Bug libfortran/93567] New: G edit descriptor uses E instead F editing in rounding mode UP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93567 Bug ID: 93567 Summary: G edit descriptor uses E instead F editing in rounding mode UP Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich+gccbug at gmail dot com Target Milestone: --- G editing is supposed to use F editing when the number fits in d digits, which it does in the following example #1. But when "RU" is specified (example #2), it does not. 99.0_8 is a real number with an exact internal representation (whole number), so this is also different from example #3. #2 is clearly a bug. program test_rug print"(G8.2)", 99.0_8 ! 99. print "(RU,G8.2)", 99.0_8 ! 0.99E+02 expected 99. print "(RU,G8.2)", 99.01_8 ! 0.10E+03 end "... the method of representation in the output field depends on the magnitude of the internal value being edited. ... If the internal value is a number other than zero, let N be the decimal value that is the result of converting the internal value to d significant digits according to the input/output rounding mode and let s be the integer such that 10^(s−1) ≤ |N| < 10^s. If s < 0 or s > d, kPEw.d or kPEw.dEe editing is used for Gw.d editing or Gw.dEe editing respectively, where k is the scale factor (13.8.5). If 0 ≤ s ≤ d, the scale factor has no effect and F(w − n).(d − s),n(’b’) editing is used where b is a blank and n is 4 for Gw.d editing, e + 2 for Gw.dEe editing if e > 0, and 4 for Gw.dE0 editing." In example #2: N=99 10^1 ≤ 99 < 10^2 d = s = 2 so F editing would have to be used.
[Bug libfortran/93592] New: Invalid UP/DOWN rounding with EN descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93592 Bug ID: 93592 Summary: Invalid UP/DOWN rounding with EN descriptor Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich+gccbug at gmail dot com Target Milestone: --- When using the EN descriptor with d=0 (ENw.0) and rounding mode UP or DOWN the result is totally wrong: program test_en print "(RU,EN9.0)", 800.0_8 ! 8.E+00 expected 800.E+00 print "(RU,EN9.0)", 901.0_8 ! 10.E+00 expected 901.E+00 print "(RD,EN9.0)", -999.6_8 ! -10.E+00 expected -1.E+03 end
[Bug fortran/47660] Retain warning text of -Wconversion messages when -Wconversion-extra is in effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47660 Thomas Henlich changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Thomas Henlich --- (In reply to Dominique d'Humieres from comment #2) > > -Wconversion-extra > > Warn about implicit conversions between different types and kinds. > > This option does not imply -Wconversion. This last sentence was added after 4.6.0 and renders the original complaint obsolete. "-Wconversion -Wconversion-extra" works as expected. Closing as Invalid.
[Bug fortran/90290] New: -std=f2008 should reject non-constant stop and error stop codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90290 Bug ID: 90290 Summary: -std=f2008 should reject non-constant stop and error stop codes Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich+gccbug at gmail dot com Target Milestone: --- According to Fortran 2008, a stop-code in a stop-stmt or error-stop-stmt must be either scalar-default-char-constant-expr or scalar-int-constant-expr (Fortran 2018: scalar-default-char-expr or scalar-int-expr) The following: program errorstop integer :: ec read *, ec stop ec end program compiles successfully with -std=f2008. It should not: while the program is Fortran 2018 compliant, it is not Fortran 2008 compliant.
[Bug fortran/90290] -std=f2008 should reject non-constant stop and error stop codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90290 --- Comment #2 from Thomas Henlich --- The road to standards non-compliance hell is paved with very minor offenses... ;-)
[Bug fortran/90374] New: Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 Bug ID: 90374 Summary: Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich+gccbug at gmail dot com Target Milestone: --- The new features of Fortran 2018 (ISO/IEC JTC1/SC22/WG5 N2145): "5.5 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors It was anomalous that the field width w was allowed to be given as zero for some output g editing, but not for d, e, es, en, and all g output editing. This has been corrected. If the value is zero, the processor selects the smallest positive actual field width that does not result in a field filled with asterisks. A zero value for the field width is not permitted for input. The g0.d edit descriptor can be used to specify the output of integer, logical, and character data. It follows the rules for the i0, l1, and a edit descriptors, respectively. The value 0 may be given to an exponent digits parameter in an ew.d ee edit descriptor. The effect of this is that the processor uses the minimum number of digits required to represent the exponent value. This avoids leading zeros, which are unsightly and can cause errors if the value is read in another language." This would be useful to have.
