[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #38 from Jerry DeLisle --- Fixed on trunk and 13
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #37 from GCC Commits --- The releases/gcc-13 branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:fbe5e908de76aa240bbcd2f144c156eccc863604 commit r13-8321-gfbe5e908de76aa240bbcd2f144c156eccc863604 Author: Jerry DeLisle Date: Fri Feb 2 18:12:33 2024 -0800 libgfortran: EN0.0E0 and ES0.0E0 format editing. F2018 and F2023 standards added zero width exponents. This required additional special handing in the process of building formatted floating point strings. G formatting uses either F or E formatting as documented in write_float.def comments. This logic changes the format token from FMT_G to FMT_F or FMT_E. The new formatting requirements interfere with this process when a FMT_G float string is being built. To avoid this, a new component called 'pushed' is added to the fnode structure to save this condition. The 'pushed' condition is then used to bypass portions of the new ES,E,EN, and D formatting, falling through to the existing default formatting which is retained. libgfortran/ChangeLog: PR libfortran/111022 * io/format.c (get_fnode): Update initialization of fnode. (parse_format_list): Initialization. * io/format.h (struct fnode): Added the new 'pushed' component. * io/write.c (select_buffer): Whitespace. (write_real): Whitespace. (write_real_w0): Adjust logic for the d == 0 condition. * io/write_float.def (determine_precision): Whitespace. (build_float_string): Calculate width of ..E0 exponents and adjust logic accordingly. (build_infnan_string): Whitespace. (CALCULATE_EXP): Whitespace. (quadmath_snprintf): Whitespace. (determine_en_precision): Whitespace. gcc/testsuite/ChangeLog: PR libfortran/111022 * gfortran.dg/fmt_error_10.f: Show D+0 exponent. * gfortran.dg/pr96436_4.f90: Show E+0 exponent. * gfortran.dg/pr96436_5.f90: Show E+0 exponent. * gfortran.dg/pr111022.f90: New test. (cherry picked from commit d436e8e70dacd9c06247bb56d0abeded8fcb4242)
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #36 from Jerry DeLisle --- I was looking for my damnit doll until I got to your last post. Is this one worthy of backport?
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #35 from nightstrike --- (In reply to anlauf from comment #34) > Are you sure that it finds the right new libgfortran? Good call. I did a make install first and re-ran it, and they all pass now. Sorry for the noise, this is an unfortunate aspect of the testsuite where in many cases it will not use the just-built libraries, but instead picks up the libraries in the install path.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #34 from anlauf at gcc dot gnu.org --- (In reply to nightstrike from comment #33) > I modified the test further to just print which ones would have called stop. > Almost, but not all, do: > > stop 2 > stop 3 > stop 4 > stop 7 > stop 8 > stop 9 > stop 10 > stop 11 > stop 12 > stop 13 > stop 15 > stop 20 > stop 21 > stop 22 > stop 23 > stop 24 > stop 25 > stop 26 > stop 27 > stop 28 > stop 29 > stop 30 > stop 31 > stop 32 Are you sure that it finds the right new libgfortran?
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #33 from nightstrike --- I modified the test further to just print which ones would have called stop. Almost, but not all, do: stop 2 stop 3 stop 4 stop 7 stop 8 stop 9 stop 10 stop 11 stop 12 stop 13 stop 15 stop 20 stop 21 stop 22 stop 23 stop 24 stop 25 stop 26 stop 27 stop 28 stop 29 stop 30 stop 31 stop 32
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #32 from nightstrike --- (In reply to anlauf from comment #31) > (In reply to nightstrike from comment #30) > > (In reply to GCC Commits from comment #29) > > > * gfortran.dg/pr111022.f90: New test. > > > > This new test fails of x64 mingw. > > Can you be more specific? Sure, it exits with STOP 2, which is the following: write(buffer,"(EN0.3E0)") 6.660_4 if (buffer.ne."6.660E+0") stop 2 I modified that as: write(buffer,"(EN0.3E0)") 6.660_4 if (buffer.ne."6.660E+0") then print *, buffer stop 2 end if And now it prints: 6.660 STOP 2 So I guess it's losing the E+0 from the string?
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #31 from anlauf at gcc dot gnu.org --- (In reply to nightstrike from comment #30) > (In reply to GCC Commits from comment #29) > > * gfortran.dg/pr111022.f90: New test. > > This new test fails of x64 mingw. Can you be more specific?
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #30 from nightstrike --- (In reply to GCC Commits from comment #29) > * gfortran.dg/pr111022.f90: New test. This new test fails of x64 mingw.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #29 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:d436e8e70dacd9c06247bb56d0abeded8fcb4242 commit r14-8779-gd436e8e70dacd9c06247bb56d0abeded8fcb4242 Author: Jerry DeLisle Date: Fri Feb 2 18:12:33 2024 -0800 libgfortran: EN0.0E0 and ES0.0E0 format editing. F2018 and F2023 standards added zero width exponents. This required additional special handing in the process of building formatted floating point strings. G formatting uses either F or E formatting as documented in write_float.def comments. This logic changes the format token from FMT_G to FMT_F or FMT_E. The new formatting requirements interfere with this process when a FMT_G float string is being built. To avoid this, a new component called 'pushed' is added to the fnode structure to save this condition. The 'pushed' condition is then used to bypass portions of the new ES,E,EN, and D formatting, falling through to the existing default formatting which is retained. libgfortran/ChangeLog: PR libfortran/111022 * io/format.c (get_fnode): Update initialization of fnode. (parse_format_list): Initialization. * io/format.h (struct fnode): Added the new 'pushed' component. * io/write.c (select_buffer): Whitespace. (write_real): Whitespace. (write_real_w0): Adjust logic for the d == 0 condition. * io/write_float.def (determine_precision): Whitespace. (build_float_string): Calculate width of ..E0 exponents and adjust logic accordingly. (build_infnan_string): Whitespace. (CALCULATE_EXP): Whitespace. (quadmath_snprintf): Whitespace. (determine_en_precision): Whitespace. gcc/testsuite/ChangeLog: PR libfortran/111022 * gfortran.dg/fmt_error_10.f: Show D+0 exponent. * gfortran.dg/pr96436_4.f90: Show E+0 exponent. * gfortran.dg/pr96436_5.f90: Show E+0 exponent. * gfortran.dg/pr111022.f90: New test.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #28 from Jerry DeLisle --- Created attachment 57260 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57260=edit A final patch This patch provides the necessary changes with only minor adjustment to existing gfortran test cases. (This took insanely longer than I had hoped and such is life.) I am preparing one or two additional test cases and will submit this for approval on the list.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #27 from Jerry DeLisle --- (In reply to anlauf from comment #26) > (In reply to Jerry DeLisle from comment #24) > > Currently gfortran does the following: > > > > character(20) :: fmt > > character(9) :: buffer > > fmt = "(1a1,d0.2,1a1)" > > write(buffer,fmt) ">", 3.0, "<" > > print *, buffer > > fmt = "(1a1,e0.2,1a1)" > > write(buffer,fmt) ">", 3.0, "<" > > print *, buffer > > end > > > > > > $ gfc question.f90 > > $ ./a.out > > >0.30D+1< > > >0.30E+1< > > > > Why not: > > > > $ ./a.out > > >3.00D+0< > > >3.00E+0< > > It seems the Fortran standard changed here between F2018 and F2023. > > F2018, Table 13.1: > > Ew.d |exp| ≤ 99E±z1z2 or ±0z1 z2 > 99 < |exp| ≤ 999 ±z1 z2z3 > > So Intel implements this. > > > > F2023, Table 13.1: > > Ew.d E0 or E0.dany E±z1 z2 . . . zs > Yes it changed. I am looking at a lot of different cases here as I have time and intuitively the 0.30D+1 caught my attention. Its not necessarily related to this bug. I also have the latest standard (2023) in front of me here.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #26 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #24) > Currently gfortran does the following: > > character(20) :: fmt > character(9) :: buffer > fmt = "(1a1,d0.2,1a1)" > write(buffer,fmt) ">", 3.0, "<" > print *, buffer > fmt = "(1a1,e0.2,1a1)" > write(buffer,fmt) ">", 3.0, "<" > print *, buffer > end > > > $ gfc question.f90 > $ ./a.out > >0.30D+1< > >0.30E+1< > > Why not: > > $ ./a.out > >3.00D+0< > >3.00E+0< It seems the Fortran standard changed here between F2018 and F2023. F2018, Table 13.1: Ew.d |exp| ≤ 99E±z1z2 or ±0z1 z2 99 < |exp| ≤ 999 ±z1 z2z3 So Intel implements this. F2023, Table 13.1: Ew.d E0 or E0.dany E±z1 z2 . . . zs with footnote: (1) where each z is a digit, and s is the minimum number of digits required to represent the exponent. A plus sign is produced if the exponent value is zero.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #25 from john.harper at vuw dot ac.nz --- With that program Intel's two compilers (ifort and ifx) both print >.30D+01< >.30E+01< If your program removes the d0.2 stuff and changes e0.2 to es0.2e0, i.e. character(20) :: fmt character(9) :: buffer fmt = "(1a1,es0.2e0,1a1)" write(buffer,fmt) ">", 3.0, "<" print *, buffer end then both Intel compilers print what you seem to have hoped for: >3.00E+0< but my gfortran, gcc version 13.1.0 (Ubuntu 13.1.0-8ubuntu1~22.04), prints >3.00< I won't argue about the difference between gfortran's >0.30D+1< and Intel's >.30D+01< because I have been caught before by whether the zero before the decimal point and the zero after the D are optional. The f2018 standard is not easy to read on this. I tried aocc-flang on your original program, and I ought to send them a bug report because it printed >< >< I don't have access to the NAG compiler or anyone else's flang. John On Thu, 25 Jan 2024, jvdelisle at gcc dot gnu.org wrote: > Date: Thu, 25 Jan 2024 22:21:01 +0000 > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Fri, 26 Jan 2024 11:21:15 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #24 from Jerry DeLisle --- > Currently gfortran does the following: > > character(20) :: fmt > character(9) :: buffer > fmt = "(1a1,d0.2,1a1)" > write(buffer,fmt) ">", 3.0, "<" > print *, buffer > fmt = "(1a1,e0.2,1a1)" > write(buffer,fmt) ">", 3.0, "<" > print *, buffer > end > > > $ gfc question.f90 > $ ./a.out > >0.30D+1< > >0.30E+1< > > Why not: > > $ ./a.out > >3.00D+0< > >3.00E+0< > > What does Intel do? > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #24 from Jerry DeLisle --- Currently gfortran does the following: character(20) :: fmt character(9) :: buffer fmt = "(1a1,d0.2,1a1)" write(buffer,fmt) ">", 3.0, "<" print *, buffer fmt = "(1a1,e0.2,1a1)" write(buffer,fmt) ">", 3.0, "<" print *, buffer end $ gfc question.f90 $ ./a.out >0.30D+1< >0.30E+1< Why not: $ ./a.out >3.00D+0< >3.00E+0< What does Intel do?
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #23 from john.harper at vuw dot ac.nz --- Jerry I agree that that's what the standard says, though I find it odd that it allows neither 666E0 nor 666E+0 nor 666+0 in output, because any of the three would be valid input of the real value 666. But you are editing a compiler to comply with the standard, and neither of us is editing the standard itself :-) John On Sun, 15 Oct 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Sun, 15 Oct 2023 02:12:25 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Sun, 15 Oct 2023 15:13:03 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #22 from Jerry DeLisle --- > Sorry for delays. I am back looking at this. > > My take on the table 13.2 for the case: EN0.0E0 > > No matter what the E for the exponent must be shown. > > If the exponent is 0 then a plus sign must be shown. > > The value for 666. then must be 666.E+0 > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #22 from Jerry DeLisle --- Sorry for delays. I am back looking at this. My take on the table 13.2 for the case: EN0.0E0 No matter what the E for the exponent must be shown. If the exponent is 0 then a plus sign must be shown. The value for 666. then must be 666.E+0
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #21 from Jerry DeLisle --- (In reply to john.harper from comment #20) > With the first test case all the EN outputs were 666. but the Fortran 2018 > standard 13.7.2.3.4 paragraph 2 requires that EN0.0 produce 666.E+0 but > Table 13.2 first ENw.d line appears to require either 666.E+00 or 666.+000 > unless my copy of F2018 is out of date. (I note that the F2023 standard > removed the ambiguity by including "with w > 0" in the offending line of > Table 13.2.) However F2018 is unambiguous and agrees with F2023 on > EN0.0E0, requiring 666.E+0 > > With the second test case, which used 66600, I think all Jerry's outputs > are correct. I did not touch the code that writes the Exponent parts yet. So will have a look.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #20 from john.harper at vuw dot ac.nz --- With the first test case all the EN outputs were 666. but the Fortran 2018 standard 13.7.2.3.4 paragraph 2 requires that EN0.0 produce 666.E+0 but Table 13.2 first ENw.d line appears to require either 666.E+00 or 666.+000 unless my copy of F2018 is out of date. (I note that the F2023 standard removed the ambiguity by including "with w > 0" in the offending line of Table 13.2.) However F2018 is unambiguous and agrees with F2023 on EN0.0E0, requiring 666.E+0 With the second test case, which used 66600, I think all Jerry's outputs are correct. On Mon, 4 Sep 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Mon, 4 Sep 2023 17:12:30 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Tue, 5 Sep 2023 05:12:45 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #18 from Jerry DeLisle --- > With Johns test case from Comment #15 and the patch in Comment #17 I get the > following: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > Notice that the width of exponents is also minimized and where the exponent is > zero it is not shown at all. If I do specify an exponent width it shown. For > example with exponent width of 4 and changing the value to 66600 I get: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > This seems reasonable to me. Other opinions? > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #19 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #18) > With Johns test case from Comment #15 and the patch in Comment #17 I get the > following: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. Intel prints With (A,1X,EN0.0E0) 666.+0 which I think is slightly more in accordance with F2018 Table 13.2, which requires printing the exponent for the ...E0 version with the minimum number of digits, which is 1 for a zero exponent. See the "footnote (1)" there. Can you please check? Or am I missing something? > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > Notice that the width of exponents is also minimized and where the exponent > is zero it is not shown at all. If I do specify an exponent width it shown. > For example with exponent width of 4 and changing the value to 66600 I get: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > This seems reasonable to me. Other opinions?
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #18 from Jerry DeLisle --- With Johns test case from Comment #15 and the patch in Comment #17 I get the following: $ ./a.out real kinds 4 8 10 16 With (A,1X,EN0.0 ) 666. With (A,1X,EN0.0 ) 666. With (A,1X,EN0.0 ) 666. With (A,1X,EN0.0 ) 666. With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666. With (A,1X,ES0.0 ) 7.E+2 With (A,1X,ES0.0 ) 7.E+2 With (A,1X,ES0.0 ) 7.E+2 With (A,1X,ES0.0 ) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 ERROR STOP Scale factor out of range in format specifier 'E' or 'D' Notice that the width of exponents is also minimized and where the exponent is zero it is not shown at all. If I do specify an exponent width it shown. For example with exponent width of 4 and changing the value to 66600 I get: $ ./a.out real kinds 4 8 10 16 With (A,1X,EN0.0 ) 67.E+3 With (A,1X,EN0.0 ) 67.E+3 With (A,1X,EN0.0 ) 67.E+3 With (A,1X,EN0.0 ) 67.E+3 With (A,1X,EN0.0E4) 67.E+0003 With (A,1X,EN0.0E4) 67.E+0003 With (A,1X,EN0.0E4) 67.E+0003 With (A,1X,EN0.0E4) 67.E+0003 With (A,1X,ES0.0 ) 7.E+4 With (A,1X,ES0.0 ) 7.E+4 With (A,1X,ES0.0 ) 7.E+4 With (A,1X,ES0.0 ) 7.E+4 With (A,1X,ES0.0E4) 7.E+0004 With (A,1X,ES0.0E4) 7.E+0004 With (A,1X,ES0.0E4) 7.E+0004 With (A,1X,ES0.0E4) 7.E+0004 ERROR STOP Scale factor out of range in format specifier 'E' or 'D' This seems reasonable to me. Other opinions?
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #17 from Jerry DeLisle ---
Preliminary patch:
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 5d47a6d25f7..aafbd96b65a 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1784,8 +1784,6 @@ write_real_w0 (st_parameter_dt *dtp, const char *source,
int kind,
set_fnode_default (dtp, , kind);
- if (f->u.real.d > 0)
-ff.u.real.d = f->u.real.d;
ff.format = f->format;
/* For FMT_G, Compensate for extra digits when using scale factor, d
@@ -1793,11 +1791,17 @@ write_real_w0 (st_parameter_dt *dtp, const char
*source, int kind,
is used. */
if (f->format == FMT_G)
{
+ if (f->u.real.d > 0)
+ ff.u.real.d = f->u.real.d;
if (dtp->u.p.scale_factor > 0 && f->u.real.d == 0)
comp_d = 1;
else
comp_d = 0;
}
+ else
+if (f->u.real.d >= 0)
+ ff.u.real.d = f->u.real.d;
+
if (f->u.real.e >= 0)
ff.u.real.e = f->u.real.e;
I have regression tested this OK. I do want to watch out for any surprises so I
am still testing.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #16 from Jerry DeLisle --- (In reply to john.harper from comment #15) > My previous test program tried Ex0.0E0 output but not Ex0.0, where x is > N,S, or absent. Below is a revised version which includes all 6 cases. > It also tries EN and ES before trying E, with an error stop if an error > is detected. Below the program is its output from ifort, which I think > is f2018-compliant, compiled with options -standard-semantics -check all Thanks John, test cases are always helpful.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #15 from john.harper at vuw dot ac.nz --- My previous test program tried Ex0.0E0 output but not Ex0.0, where x is N,S, or absent. Below is a revised version which includes all 6 cases. It also tries EN and ES before trying E, with an error stop if an error is detected. Below the program is its output from ifort, which I think is f2018-compliant, compiled with options -standard-semantics -check all (All lines of gfortran output after the first appeared to be wrong.) program testen0es0e0 ! EN0.0,ES0.0 good f2018, E0.0 bad, with E0 or not integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & p3 = selected_real_kind(precision(1.0_p2)+1), & hp = selected_real_kind(precision(1.0_p3)+1), & p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 character:: ens(3)*2=["EN","ES"," E"],e0(2)*2=[" ","E0"], fmt*14, & msg*200 integer iens,ie0,ios write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 do iens = 1,3 do ie0 = 1,2 fmt = "(A,1X,"//ens(iens)//"0.0"//e0(ie0)//")" write(*, fmt,iostat=ios,iomsg=msg) 'With '//fmt, 666.0_p1 if(ios/=0) error stop trim(msg) write(*, fmt) 'With '//fmt, 666.0_p2 write(*, fmt) 'With '//fmt, 666.0_p3 if(p3/=p4) write(*, fmt) 'With '//fmt, 666.0_p4 end do end do end program testen0es0e0 real kinds 4 8 16 16 With (A,1X,EN0.0 ) 666.E+00 With (A,1X,EN0.0 ) 666.E+00 With (A,1X,EN0.0 ) 666.E+00 With (A,1X,EN0.0E0) 666.E+0 With (A,1X,EN0.0E0) 666.E+0 With (A,1X,EN0.0E0) 666.E+0 With (A,1X,ES0.0 ) 7.E+02 With (A,1X,ES0.0 ) 7.E+02 With (A,1X,ES0.0 ) 7.E+02 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X, E0.0 ) * output conversion error, unit 6, file /dev/pts/0 -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #14 from john.harper at vuw dot ac.nz --- To add to my email copied below, you may find a reference to the standards helpful. k is the scale factor referred to in F2018 or F2023 13.7.2.3.3. The last paragraph of that says that in Ew.d and Ew.dE0 output format, one of these two inequalities must be satisfied: -d < k <= 0 or 0 < k < d+2. With either E0.0 or E0.0E0 the value of k is not permitted. On Sun, 27 Aug 2023, john.harper at vuw dot ac.nz wrote: > Date: Sun, 27 Aug 2023 21:40:58 + > From: john.harper at vuw dot ac.nz > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Mon, 28 Aug 2023 09:41:10 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #11 from john.harper at vuw dot ac.nz --- > Jerry's test program is identical with mine. > Because E format is supposed to give no digits before the decimal point > except possibly a leading zero, E0.0 and E0.0E0 are both pointless, and > Steve Lionel pointed out in Fortran Discourse that the standard forbids > them because they would generate an illegal value of k for the kP edit > descriptor (which happens not to be explicitly used here.) So I think > gfortran ought to give a run-time error for it. If I compiled the program > with ifort and more warning options, the first 2 write statements gave > > real kinds 4 8 16 16 > With (A,1X, E0.0E0) * > forrtl: error (63): output conversion error, unit 6, file /dev/pts/1 > > The ES result from gfortran was correct and standard-conforming. The EN > one should have said 666.E+0 not 666. > > On Sun, 27 Aug 2023, jvdelisle at gcc dot gnu.org wrote: > >> Date: Sun, 27 Aug 2023 15:38:33 +0000 >> From: jvdelisle at gcc dot gnu.org >> To: John Harper >> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d >> too >> high. >> Resent-Date: Mon, 28 Aug 2023 03:38:51 +1200 (NZST) >> Resent-From: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 >> >> --- Comment #9 from Jerry DeLisle --- >> I am using this: >> >> program teste0es0en0 >> integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & >> p3 = selected_real_kind(precision(1.0_p2)+1), & >> hp = selected_real_kind(precision(1.0_p3)+1), & >> p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 >> character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " >> integer ifmt >> write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 >> do ifmt = 1,3 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 >> if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 >> end do >> end program teste0es0en0 >> >> And I get the following output with some test patching: >> >> $ ./a.out >> real kinds 4 8 10 16 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> >> -- >> You are receiving this mail because: >> You reported the bug. >> > > > -- John Harper, School of Mathematics and Statistics > Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. > e-mail john.har...@vuw.ac.nz > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #13 from john.harper at vuw dot ac.nz --- Hmmm. If I read anlauf correctly, our versions of ifort differ when writing ES0.0E0 and EN0.0E0 with the value 666.0. Both give the same correct numerical values but one version omits the E in the output. Omitting it does write the value in the shortest possible space but disobeys the F2018 and F2023 standards, where 13.7.2.3.4 Table 13.2 and 13.7.2.3.5 Table 13.3 require ENw.dE0 and ESw.dE0 to include E in the output. On Sun, 27 Aug 2023, anlauf at gcc dot gnu.org wrote: > Date: Sun, 27 Aug 2023 19:41:10 + > From: anlauf at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Mon, 28 Aug 2023 07:41:23 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #10 from anlauf at gcc dot gnu.org --- > (In reply to Jerry DeLisle from comment #9) >> I am using this: >> >> program teste0es0en0 >> integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & >>p3 = selected_real_kind(precision(1.0_p2)+1), & >>hp = selected_real_kind(precision(1.0_p3)+1), & >>p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 >> character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " >> integer ifmt >> write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 >> do ifmt = 1,3 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 >> if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 >> end do >> end program teste0es0en0 >> >> And I get the following output with some test patching: >> >> $ ./a.out >> real kinds 4 8 10 16 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. > > Intel does not like E0.0E0, thus running with do ifmt = 2,3 gives: > > real kinds 4 8 16 16 > With (A,1X,ES0.0E0) 7.+2 > With (A,1X,ES0.0E0) 7.+2 > With (A,1X,ES0.0E0) 7.+2 > With (A,1X,EN0.0E0) 666.+0 > With (A,1X,EN0.0E0) 666.+0 > With (A,1X,EN0.0E0) 666.+0 > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #12 from Jerry DeLisle --- (In reply to john.harper from comment #11) I have the error check commented out during some of my checking on things. I will revise the test case to test for the correct error.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #11 from john.harper at vuw dot ac.nz --- Jerry's test program is identical with mine. Because E format is supposed to give no digits before the decimal point except possibly a leading zero, E0.0 and E0.0E0 are both pointless, and Steve Lionel pointed out in Fortran Discourse that the standard forbids them because they would generate an illegal value of k for the kP edit descriptor (which happens not to be explicitly used here.) So I think gfortran ought to give a run-time error for it. If I compiled the program with ifort and more warning options, the first 2 write statements gave real kinds 4 8 16 16 With (A,1X, E0.0E0) * forrtl: error (63): output conversion error, unit 6, file /dev/pts/1 The ES result from gfortran was correct and standard-conforming. The EN one should have said 666.E+0 not 666. On Sun, 27 Aug 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Sun, 27 Aug 2023 15:38:33 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Mon, 28 Aug 2023 03:38:51 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #9 from Jerry DeLisle --- > I am using this: > > program teste0es0en0 > integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & > p3 = selected_real_kind(precision(1.0_p2)+1), & > hp = selected_real_kind(precision(1.0_p3)+1), & > p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 > character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " > integer ifmt > write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 > do ifmt = 1,3 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 > if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 > end do > end program teste0es0en0 > > And I get the following output with some test patching: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #9) > I am using this: > > program teste0es0en0 > integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & >p3 = selected_real_kind(precision(1.0_p2)+1), & >hp = selected_real_kind(precision(1.0_p3)+1), & >p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 > character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " > integer ifmt > write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 > do ifmt = 1,3 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 > if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 > end do > end program teste0es0en0 > > And I get the following output with some test patching: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. Intel does not like E0.0E0, thus running with do ifmt = 2,3 gives: real kinds 4 8 16 16 With (A,1X,ES0.0E0) 7.+2 With (A,1X,ES0.0E0) 7.+2 With (A,1X,ES0.0E0) 7.+2 With (A,1X,EN0.0E0) 666.+0 With (A,1X,EN0.0E0) 666.+0 With (A,1X,EN0.0E0) 666.+0
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #9 from Jerry DeLisle --- I am using this: program teste0es0en0 integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & p3 = selected_real_kind(precision(1.0_p2)+1), & hp = selected_real_kind(precision(1.0_p3)+1), & p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " integer ifmt write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 do ifmt = 1,3 write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 end do end program teste0es0en0 And I get the following output with some test patching: $ ./a.out real kinds 4 8 10 16 With (A,1X, E0.0E0) 1.E+3 With (A,1X, E0.0E0) 1.E+3 With (A,1X, E0.0E0) 1.E+3 With (A,1X, E0.0E0) 1.E+3 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #8 from john.harper at vuw dot ac.nz --- I couldn't see the program teste0es0en0.f90 that is in your bugzilla but I could see that it does have 691 bytes. So does one of the two versions that I now have in my own computer. The attachment to this email contains that version and what ifort did with it. (Of course E0.0E0 is illegal Fortran but ES0.0E0 and EN0.0E0 are OK according to both the f2018 and f2023 standards.) On Sat, 26 Aug 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Sat, 26 Aug 2023 04:26:51 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Sat, 26 Aug 2023 16:27:07 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > Jerry DeLisle changed: > > What|Removed |Added > > Status|NEW |ASSIGNED > > --- Comment #7 from Jerry DeLisle --- > I don't have ifort installed at the moment. Would someone post the output from > ifort with teste0es0en0.f90 attached to this PR? Much appreciated. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Jerry DeLisle --- I don't have ifort installed at the moment. Would someone post the output from ifort with teste0es0en0.f90 attached to this PR? Much appreciated.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #6 from Jerry DeLisle --- (In reply to john.harper from comment #5) Thanks John, I had a moment to look at this. I know where to do the implementation but I have not decided how yet.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #5 from john.harper at vuw dot ac.nz --- True. I reported the bug because in ESw.dEe output format all 3 of w,d,e may be 0, but gfortran then gave the right numerical result in the wrong format with my test programs. (I'm told NAG hasn't yet implemented ES0.0E0 but ifort has got it right.) On Wed, 16 Aug 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Wed, 16 Aug 2023 03:39:58 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Wed, 16 Aug 2023 15:40:09 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #4 from Jerry DeLisle --- > The relative text in the standard is: > > 13.7.2.1 General rules > --- snip --- > (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. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #4 from Jerry DeLisle --- The relative text in the standard is: 13.7.2.1 General rules --- snip --- (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.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle --- Yes I will take. I did not notice this change.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #2 from john.harper at vuw dot ac.nz --- Further information on this bug: it affects all four real kinds with all three of E0.0E0, ES0.0E0 and EN0.0E0 formats. My 15-line test program for that is attached. I hope it helps. On Tue, 15 Aug 2023, anlauf at gcc dot gnu.org wrote: > Date: Tue, 15 Aug 2023 19:45:06 + > From: anlauf at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Wed, 16 Aug 2023 07:45:16 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > anlauf at gcc dot gnu.org changed: > > What|Removed |Added > > Status|UNCONFIRMED |NEW > Ever confirmed|0 |1 > CC||jvdelisle at gcc dot gnu.org > Component|fortran |libfortran > Keywords||wrong-code > Last reconfirmed||2023-08-15 > > --- Comment #1 from anlauf at gcc dot gnu.org --- > Confirmed. > > @Jerry: can you have a look? F2008 did not specify w=0 for the ES format; > this was added in F2018. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||jvdelisle at gcc dot gnu.org Component|fortran |libfortran Keywords||wrong-code Last reconfirmed||2023-08-15 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. @Jerry: can you have a look? F2008 did not specify w=0 for the ES format; this was added in F2018.
