[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #54 from Jerry DeLisle 2011-05-06 01:29:40 UTC --- I am closing this PR. The original issues are resolved. I am opening a new PR to address the problem identified in Comment #37 The new PR is PR48906 Thanks for these reports and look to the new PR for continuation.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #53 from Jerry DeLisle 2011-05-05 12:35:46 UTC --- The test: print "(1pg7.1)", 0.96 end Fails in 4.4 and works in 4.5, so this confirms it was fixed quite a while ago. I strongly suggest you upgrade your gfortran.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #52 from jvdelisle at frontier dot com 2011-05-05 12:30:38 UTC --- On 05/05/2011 04:01 AM, ebay.20.tedlap at spamgourmet dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 > > --- Comment #51 from Lionel GUEZ > 2011-05-05 10:46:21 UTC --- >> It is PR48787 and a patch has been submitted for approval. It is fixed on my >> development trunk. > > Hello. I do not understand: you say that there is a patch submitted for > approval while Thomas Henlich says the bug is already fixed in Gfortran 4.4.5. > I thought what you were seeing was part of what we have just been fixing. It is possible that it is an old bug we fixed a while back.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #50 from Lionel GUEZ 2011-05-05 10:42:31 UTC --- > Can you please provide a short example program, and what version of GFortran > you are using? > > I cannot reproduce the described bug with GFortran 4.4.5 nor with > 4.7-20110430. > Your expected result is correctly produced by the program: > > print "(1pg7.1)", 0.96 > end > > => 1. Here is the test on my machine: $ gfortran --version GNU Fortran (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2010 Free Software Foundation, Inc. $ cat short_test.f90 print "(1pg7.1)", 0.96 end $ gfortran short_test.f90 $ a.out 0.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #51 from Lionel GUEZ 2011-05-05 10:46:21 UTC --- > It is PR48787 and a patch has been submitted for approval. It is fixed on my > development trunk. Hello. I do not understand: you say that there is a patch submitted for approval while Thomas Henlich says the bug is already fixed in Gfortran 4.4.5.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #48 from jvdelisle at frontier dot com 2011-05-04 12:30:59 UTC --- On 05/04/2011 05:15 AM, ebay.20.tedlap at spamgourmet dot com wrote: > --- Comment #47 from Lionel GUEZ > 2011-05-04 12:15:16 UTC --- > (In reply to comment #46) --- snip --- > Hello. I have noticed a bug which seems related to the one you are describing. > According to the Fortran 95 standard, printing the number 0.96 with the format > 1pg7.1 should give the same result than with format f3.0. Thus, the result > should be 1., but Gfortran produces the surprising result 0. Is it the same > bug? It is PR48787 and a patch has been submitted for approval. It is fixed on my development trunk.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #49 from Thomas Henlich 2011-05-04 12:48:28 UTC --- (In reply to comment #47) > (In reply to comment #46) > > I have started on the second phase of this effort which is to get rid of the > > floating point issue on -m32 machines. > > Hello. I have noticed a bug which seems related to the one you are describing. > According to the Fortran 95 standard, printing the number 0.96 with the format > 1pg7.1 should give the same result than with format f3.0. Thus, the result > should be 1., but Gfortran produces the surprising result 0. Is it the same > bug? > Sincerely, > Lionel GUEZ Can you please provide a short example program, and what version of GFortran you are using? I cannot reproduce the described bug with GFortran 4.4.5 nor with 4.7-20110430. Your expected result is correctly produced by the program: print "(1pg7.1)", 0.96 end => 1.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 Lionel GUEZ changed: What|Removed |Added CC||ebay.20.tedlap at ||spamgourmet dot com --- Comment #47 from Lionel GUEZ 2011-05-04 12:15:16 UTC --- (In reply to comment #46) > I have started on the second phase of this effort which is to get rid of the > floating point issue on -m32 machines. Hello. I have noticed a bug which seems related to the one you are describing. According to the Fortran 95 standard, printing the number 0.96 with the format 1pg7.1 should give the same result than with format f3.0. Thus, the result should be 1., but Gfortran produces the surprising result 0. Is it the same bug? Sincerely, Lionel GUEZ
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #46 from Jerry DeLisle 2011-05-02 12:46:11 UTC --- I have started on the second phase of this effort which is to get rid of the floating point issue on -m32 machines.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #45 from Jerry DeLisle 2011-04-29 15:09:02 UTC --- Author: jvdelisle Date: Fri Apr 29 15:08:57 2011 New Revision: 173168 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173168 Log: 2011-04-29 Jerry DeLisle PR libgfortran/48488 PR libgfortran/48602 PR libgfortran/48615 PR libgfortran/48684 PR libgfortran/48787 * gfortran.dg/fmt_g.f: Adjust test. * gfortran.dg/fmt_g0_1.f08: Adjust test. * gfortran.dg/round_3.f08: New test. * gfortran.dg/namelist_print_1.f: Adjust test. * gfortran.dg/char4_iunit_1.f03: Adjust test. * gfortran.dg/f2003_io_5.f03: Adjust test. * gfortran.dg/coarray_15.f90: Adjust test. * gfortran.dg/namelist_65.f90: Adjust test. * gfortran.dg/fmt_cache_1.f: Adjust test. * gfortran.dg/char4_iunit_2.f03: Adjust test. * gfortran.dg/real_const_3.f90: Adjust test. Added: trunk/gcc/testsuite/gfortran.dg/round_3.f08 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char4_iunit_1.f03 trunk/gcc/testsuite/gfortran.dg/char4_iunit_2.f03 trunk/gcc/testsuite/gfortran.dg/coarray_15.f90 trunk/gcc/testsuite/gfortran.dg/f2003_io_5.f03 trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f trunk/gcc/testsuite/gfortran.dg/fmt_g.f trunk/gcc/testsuite/gfortran.dg/fmt_g0_1.f08 trunk/gcc/testsuite/gfortran.dg/namelist_65.f90 trunk/gcc/testsuite/gfortran.dg/namelist_print_1.f trunk/gcc/testsuite/gfortran.dg/real_const_3.f90
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #44 from Jerry DeLisle 2011-04-29 14:56:07 UTC --- Author: jvdelisle Date: Fri Apr 29 14:56:02 2011 New Revision: 173166 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173166 Log: 2011-04-29 Jerry DeLisle Janne Blomqvist PR libgfortran/48488 PR libgfortran/48602 PR libgfortran/48615 PR libgfortran/48684 PR libgfortran/48787 * io/write.c (write_d, write_e, write_f, write_en, write_es): Add precision compemsation parameter to call. (set_fnode_default): Adjust default widths to assure round trip on write and read. (write_real): Adjust call to write_float. (write_real_g0): Calculate compensation for extra precision and adjust call to write_float. * io/write_float.def (output_float_FMT_G_): Use volatile rather than asm volatile to avoid optimization issue. Correctly calculate the number of blanks (nb) to be appended and simplify calculation logic. (write_float): Increase MIN_FIELD_WIDTH by one to accomodate the new default widths. Eliminate the code that attempted to reduce the the precision used in later sprintf functions. Add call parameter to compensate for extra precision. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write.c trunk/libgfortran/io/write_float.def
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #43 from Thomas Henlich 2011-04-23 11:44:45 UTC --- It seems the required changes would fit in nicely in output_float(): We can treat FMT_G like FMT_E. After the rounding step, i.e. when the final value of the variable e in output_float() is known (at the label 'skip'), if e is within limits for F editing, revert the formatting to F and add the blanks at the end.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #42 from Jerry DeLisle 2011-04-21 19:09:24 UTC --- Yes, I agree. My intuition was telling me our approach was wrong. I will try to come up with a patch in the next few days. No rush please with Easter coming up.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #41 from Thomas Henlich 2011-04-21 16:36:14 UTC --- Actually it may be even simpler than that: We already know how many significant digits (d) we want in the output string, and at what digit to round. So we can write the digits of the significand into a buffer (with Ew.d editing). All that would remain is to decide whether to print the exponent or not (according to a simple integer comparison), otherwise shift the decimal point to the right place (simple string operation). E.g. 0.0995 with RU,G0.2 dtoa -> ".10", exponent=0 output -> ".10" 12345000 with RD,G0.4: dtoa -> ".1234", exponent=8 output -> ".1234E+08" because exponent > d 12345678.95 with RD,G0.9: dtoa -> ".123456789", exponent=8 output -> "123456789." because exponent < d
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #40 from Jerry DeLisle 2011-04-21 12:44:54 UTC --- Reply to comment #37 Using volatile does not fix the behavior for the "if" condition. I have tried several volatile permutations on it as well. Using "volatile" rather than the "asm volatile" on the "temp" case does resolve that one and the attached case "Test program for optimization" (ie declaring temp as volatile) So, we are stuck at comment #37 at the moment. This has prompted me to think "Why are we doing this in floating point to begin with?" The Fortran Standard model assumes perfect floating representation. The r and rexp_d could be represented in exact ascii decimal form and these tests done after we generate the DTOA string representation of "m". This would require refactoring our code, but it could be done I think and the tests would then be a byte scan which in most cases would exit after a few loop iterations. I suppose this would be a bit slower. Regardless, it is an idea I toss out for comment.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #39 from Tobias Burnus 2011-04-20 13:01:34 UTC --- (In reply to comment #38) > and compile with -mpc32 -mpc64 -mpc80 respectively. Then I like Janne's proposal more: compiling libgfortran/io/*.c with -fexcess-precision=standard.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #38 from Thomas Henlich 2011-04-20 12:38:53 UTC --- As an alternative we might consider leaving the code as it was before and instead putting OUTPUT_FLOAT_FMT_G(4) OUTPUT_FLOAT_FMT_G(8) OUTPUT_FLOAT_FMT_G(10) into separate files and compile with -mpc32 -mpc64 -mpc80 respectively.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #37 from Thomas Henlich 2011-04-20 06:43:37 UTC --- The same issue exists with the first comparison (decision between FMT_E and FMT_F). Consider: print "(g35.25)", 0.095d0 ! > 0.95..11..E-01 print "(g35.25)", 0.095_10 print "(RC,G15.1)", 0.095d0 ! > 0.1E+00 expected 0.1 print "(RC,F11.1,4X)", 0.095d0
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #36 from Jerry DeLisle 2011-04-20 04:18:31 UTC --- Author: jvdelisle Date: Wed Apr 20 04:18:25 2011 New Revision: 172753 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172753 Log: 2011-04-19 Jerry DeLisle PR libgfortran/48602 * io/write_float.def (output_float_FMT_G): Fix reversal in conditional. Use asm volatile to mark temp variable, avoiding optimization errors. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #35 from Jerry DeLisle 2011-04-19 20:02:38 UTC --- That does the trick. I will regression test and commit tonight
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #34 from Tobias Burnus 2011-04-19 16:22:16 UTC --- (In reply to comment #33) > We could put that behind some compiler directives looking for -m32 or similar. Try: temp = calculate_exp(mid - 1)* (1 - r * rexp_d); asm volatile ("" : "+m" (temp)); (Thanks to Jakub for the suggestion.)
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #33 from Jerry DeLisle 2011-04-19 15:28:56 UTC --- In response to Comment #30: One solution seems to be to take away "static inline" for the function: double calculate_exp(int d) { int i; double r = 1.0; for (i = 0; i< (d >= 0 ? d : -d); i++) r *= 10; r = (d >= 0) ? r : 1.0 / r; return r; } We could put that behind some compiler directives looking for -m32 or similar. I will have to find the correct #ifdefine
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #32 from Thomas Henlich 2011-04-19 06:09:27 UTC --- (In reply to comment #30) > I can not reproduce the issue with optimization issue on my linux system > x86-64. > > Thomas, what platform do you see the problem on? I only see it on a Cygwin > installation. $ uname -a Linux debivm 2.6.26-2-686 #1 SMP Thu Jan 27 00:28:05 UTC 2011 i686 GNU/Linux $ ~/gcc-4.7-20110409/bin/gcc -O2 write_float.c && ./a.out d=2 $ ~/gcc-4.7-20110409/bin/gcc -O2 -fexcess-precision=standard write_float.c && ./a.out d=1 $ ~/gcc-4.7-20110409/bin/gcc --version gcc (GCC) 4.7.0 20110409 (experimental) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >uname -a windows32 theta 2.5.1 2600 i686-pc Intel unknown MinGW >gcc -O2 write_float.c && .\a.exe d=2 >gcc -O2 -fexcess-precision=standard write_float.c && .\a.exe d=1 >gcc --version gcc (GCC) 4.7.0 20110409 (experimental) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #31 from Tobias Burnus 2011-04-19 06:06:44 UTC --- (In reply to comment #30) > I can not reproduce the issue with optimization issue on my linux system > x86-64. I can produce it with -m32 on Linux. Most such issues occur due to the non-IEEE rounding (excess precision) when the 387 coprocessor is used. Consequently, the issue vanishes when using: -mfpmath=sse, -ffloat-store or -fexcess-precision=standard. With x86-64 SSE is used, which does not have this issue.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #30 from Jerry DeLisle 2011-04-19 02:06:52 UTC --- I can not reproduce the issue with optimization issue on my linux system x86-64. Thomas, what platform do you see the problem on? I only see it on a Cygwin installation.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #29 from Jerry DeLisle 2011-04-18 18:56:22 UTC --- I should mention that optimization issue goes away at -O3. It also goes away with -ffloat-store
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #28 from Jerry DeLisle 2011-04-18 18:46:00 UTC --- This optimization test case is cute. We should ship it to the optimization folks. And it should be yet another PR, even if we can come up with a work around. I am not going to have time to look further on this for a few days. Thomas, could you open a PR for the optimization issue and attache your c test case to it. Then add a refrence here to that new PR. Make sure you put the word "Optimization" in the PR summary so the right folks will notice it. and thanks for the great sleuthing! I am time compressed, as most of us are.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #27 from Mikael Morin 2011-04-18 08:53:30 UTC --- (In reply to comment #22) > (In reply to comment #7) > > > + case ROUND_ZERO:\ > > +r = sign_bit ? 0.0 : 1.0;\ > > This should read: > r = sign_bit ? 1.0 : 0.0;\ If you feel interested, you could start proposing patches yourself.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #25 from Thomas Henlich 2011-04-18 08:39:17 UTC --- After some testing, I found the problem to be optimization-related. It seems the following term is calculated as a long double and not rounded before the "if (m < temp)" comparison, resulting in an unexpected and in this case invalid result. temp = calculate_exp(mid - 1) * (1 - r * rexp_d); Compare: $ gcc -O2 write_float.c && ./a.out d=2 $ gcc -O2 -fexcess-precision=standard write_float.c && ./a.out d=1
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #26 from Thomas Henlich 2011-04-18 08:40:12 UTC --- Created attachment 24027 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24027 Test program for optimization
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #24 from Thomas Henlich 2011-04-18 06:32:06 UTC --- call check_all(0.995_RT, 15, 2, 0) This still fails (with RC,G15.2 /= RC,F11.1). We need to look at why. I am aware that N=.995 is .994... internally, but so is the value 1 - r x 10^-d and 1 - r x 10^-d <= N must still be true.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #22 from Thomas Henlich 2011-04-18 05:59:14 UTC --- (In reply to comment #7) > + case ROUND_ZERO:\ > +r = sign_bit ? 0.0 : 1.0;\ This should read: r = sign_bit ? 1.0 : 0.0;\ Attaching modified test.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #23 from Thomas Henlich 2011-04-18 05:59:55 UTC --- Created attachment 24025 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24025 Updated test
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #21 from Jerry DeLisle 2011-04-18 03:58:25 UTC --- Fixed on trunk. Shall we close?
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #20 from Jerry DeLisle 2011-04-18 03:53:02 UTC --- Author: jvdelisle Date: Mon Apr 18 03:52:59 2011 New Revision: 172635 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172635 Log: 2011-04-17 Jerry DeLisle PR libgfortran/48602 * gfortran.dg/fmt_g0_6.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_g0_6.f08 Modified: trunk/gcc/testsuite/ChangeLog
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #19 from Jerry DeLisle 2011-04-18 03:48:28 UTC --- Author: jvdelisle Date: Mon Apr 18 03:48:25 2011 New Revision: 172634 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172634 Log: 2011-04-17 Jerry DeLisle PR libgfortran/48602 * io/write_float.def (output_float_FMT_G): Use current rounding mode to set the rounding parameters. (output_float): Skip rounding if value is zero. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #18 from jvdelisle at frontier dot com 2011-04-17 13:47:06 UTC --- On 04/17/2011 06:25 AM, thenlich at users dot sourceforge.net wrote: --- snip --- > > I agree. > > Let's open a new bug for this. This bug is about the correct choice of format, > not about rounding (this is somewhere else in the code). > Yes, new PR. We are using builtin snprintf for DTOA. #define DTOA \ snprintf (buffer, size, "%+-#" STR(MIN_FIELD_WIDTH) ".*" \ "e", ndigits - 1, tmp); By examining the buffer returned, we are getting an exact value back before we even begin processing the string for our libgfortran needs. The buffer for this case contains: buffer=990e-02 The first digit is an artifact of shifting the buffer for decimal point placement and is ignored. I still need to check the code between the call to snprintf and where I have placed a printf to view it. snprintf may be rounding the value up. Testing continues.
Re: [Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
On 04/17/2011 06:25 AM, thenlich at users dot sourceforge.net wrote: --- snip --- I agree. Let's open a new bug for this. This bug is about the correct choice of format, not about rounding (this is somewhere else in the code). Yes, new PR. We are using builtin snprintf for DTOA. #define DTOA \ snprintf (buffer, size, "%+-#" STR(MIN_FIELD_WIDTH) ".*" \ "e", ndigits - 1, tmp); By examining the buffer returned, we are getting an exact value back before we even begin processing the string for our libgfortran needs. The buffer for this case contains: buffer=990e-02 The first digit is an artifact of shifting the buffer for decimal point placement and is ignored. I still need to check the code between the call to snprintf and where I have placed a printf to view it. snprintf may be rounding the value up. Testing continues.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #17 from Thomas Henlich 2011-04-17 13:25:25 UTC --- (In reply to comment #16) > I see another rounding issue with this: > > integer, parameter :: RT=8 > print *, 0.09_RT, " RD:" > print "(RD,G15.2)", 0.09_RT > print "(RD,E15.2)", 0.09_RT > print "(RD,D15.2)", 0.09_RT > print "(RD,F15.2)", 0.09_RT > end > Gives: > > 8.99967E-002 RD: >0.89E-01 >0.90E-01 >0.90D-01 >0.08 > > I believe the E and D case should be 0.89E-01 and 0.89E-01 I agree. Let's open a new bug for this. This bug is about the correct choice of format, not about rounding (this is somewhere else in the code).
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #16 from Jerry DeLisle 2011-04-17 12:39:25 UTC --- I see another rounding issue with this: integer, parameter :: RT=8 print *, 0.09_RT, " RD:" print "(RD,G15.2)", 0.09_RT print "(RD,E15.2)", 0.09_RT print "(RD,D15.2)", 0.09_RT print "(RD,F15.2)", 0.09_RT end Gives: 8.99967E-002 RD: 0.89E-01 0.90E-01 0.90D-01 0.08 I believe the E and D case should be 0.89E-01 and 0.89E-01
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #15 from Thomas Henlich 2011-04-16 17:45:05 UTC --- And maybe for performance improvement we should transform if ((m > 0.0 && m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\ ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\ to: if (m > 0.0 && ((m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0)) ||\ ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\ for m == 0.0 this avoids evaluation of (rexp_d * (m + r) >= 1.0)) which is then always false anyway.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #14 from Thomas Henlich 2011-04-16 17:28:16 UTC --- (In reply to comment #13) > OK, here is what I have settled on for the IF clause after checking the > factoring. > > rexp_d = calculate_exp_ ## x (-d);\ > if ((m > 0.0 && m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\ > ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\ > { \ > newf->format = FMT_E;\ > newf->u.real.w = w;\ > newf->u.real.d = d;\ > newf->u.real.e = e;\ > nb = 0;\ > goto finish;\ > }\ > > Regression testing now. Just noticed: Shouldn't the last term in the if clause be: compile_options.allow_std & (GFC_STD_F2003 | GFC_STD_F2008) Fortran 2008 requires the F conversion for a magnitude of 0.0.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #13 from Jerry DeLisle 2011-04-16 17:06:44 UTC --- OK, here is what I have settled on for the IF clause after checking the factoring. rexp_d = calculate_exp_ ## x (-d);\ if ((m > 0.0 && m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\ ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\ { \ newf->format = FMT_E;\ newf->u.real.w = w;\ newf->u.real.d = d;\ newf->u.real.e = e;\ nb = 0;\ goto finish;\ }\ Regression testing now.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #12 from Jerry DeLisle 2011-04-16 16:10:40 UTC --- "If 0 < N < 0.1 − r × 10−d−1 or N ≥ 10d − r, or N is identically 0 and d is 0, Gw .d output editing is the same as k PEw .d output editing and Gw .d Ee output editing is the same as k PEw .d Ee output editing, where k is the scale factor (10.8.5)." I am looking at the above quoted from the standard.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #11 from Jerry DeLisle 2011-04-16 16:03:19 UTC --- Created attachment 24011 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24011 Preliminary patch, still under testing The attached is what I am currently testing. In this patch I have completely left alone the if clause where I inadvertently replaced .05 with r. This clause is apparently handling some special cases. it does seem to affect some of the default_denormal* tests in the test suite. I am still investigating it.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #10 from Thomas Henlich 2011-04-16 15:46:14 UTC --- (In reply to comment #8) > (In reply to comment #7) > > - if ((m > 0.0 && m < 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) >= 1.0) > > ||\ > > + if ((m > 0.0 && m < 0.1 - r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\ > > This can't be right, replacing 0.05 with r. It must be r / 10 or 0.1 * r. > > m < 0.1 - 0.1 * r * rexp_d > m < 0.1 * (1.0 - r * rexp_d) Jerry, there is a bug in your patch: You replaced 0.05 with r. This is not correct. In the original code the constant which is now r had a value of 0.5. So you must replace 0.05 from the original with 0.1 * r, which can be written either: if ((m > 0.0 && m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\ or if ((m > 0.0 && m < 0.1 * (1.0 - r * rexp_d)) || (rexp_d * (m + r) >= 1.0) ||\ Please post a corrected patch, so we are testing the same thing.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #9 from jvdelisle at frontier dot com 2011-04-16 14:38:23 UTC --- On 04/15/2011 11:42 PM, thenlich at users dot sourceforge.net wrote: > m< 0.1 - 0.1 * r * rexp_d > m< 0.1 * (1.0 - r * rexp_d) > Of course. I am also testing with input values other than those in your original test case. If you could do the same I would appreciate it. The more corner cases we can think of, the better.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #8 from Thomas Henlich 2011-04-16 06:42:52 UTC --- (In reply to comment #7) > - if ((m > 0.0 && m < 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) >= 1.0) ||\ > + if ((m > 0.0 && m < 0.1 - r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\ This can't be right, replacing 0.05 with r. It must be r / 10 or 0.1 * r. m < 0.1 - 0.1 * r * rexp_d m < 0.1 * (1.0 - r * rexp_d)
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #7 from Jerry DeLisle 2011-04-16 04:30:04 UTC --- Here is a patch for testing. Index: io/write_float.def === --- io/write_float.def(revision 172502) +++ io/write_float.def(working copy) @@ -822,7 +822,7 @@ output_float_FMT_G_ ## x (st_parameter_dt *dtp, co int d = f->u.real.d;\ int w = f->u.real.w;\ fnode *newf;\ - GFC_REAL_ ## x rexp_d;\ + GFC_REAL_ ## x rexp_d, r = 0.5;\ int low, high, mid;\ int ubound, lbound;\ char *p, pad = ' ';\ @@ -832,8 +832,26 @@ output_float_FMT_G_ ## x (st_parameter_dt *dtp, co save_scale_factor = dtp->u.p.scale_factor;\ newf = (fnode *) get_mem (sizeof (fnode));\ \ + switch (dtp->u.p.current_unit->round_status)\ +{\ + case ROUND_ZERO:\ +r = sign_bit ? 0.0 : 1.0;\ +break;\ + case ROUND_UP:\ +r = 1.0;\ +break;\ + case ROUND_DOWN:\ +r = 0.0;\ +break;\ + case ROUND_NEAREST:\ + case ROUND_PROCDEFINED:\ + case ROUND_UNSPECIFIED:\ + case ROUND_COMPATIBLE:\ +break;\ +}\ +\ rexp_d = calculate_exp_ ## x (-d);\ - if ((m > 0.0 && m < 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) >= 1.0) ||\ + if ((m > 0.0 && m < 0.1 - r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\ ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\ { \ newf->format = FMT_E;\ @@ -855,7 +873,7 @@ output_float_FMT_G_ ## x (st_parameter_dt *dtp, co GFC_REAL_ ## x temp;\ mid = (low + high) / 2;\ \ - temp = (calculate_exp_ ## x (mid - 1) * (1 - 0.5 * rexp_d));\ + temp = (calculate_exp_ ## x (mid - 1) * (1 - r * rexp_d));\ \ if (m < temp)\ { \
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #6 from Jerry DeLisle 2011-04-15 20:57:31 UTC --- Ha, OK thanks. I see it.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #5 from Thomas Henlich 2011-04-15 20:41:02 UTC --- (In reply to comment #4) > OK I knew I was "looking" at it wrong. The formulas you mention we are using > and are in write_float.def starting at line 798. The table is there as well. I > have been exploring the code here but have not spotted it yet. The issue > could > either be in this formula implementation or in the rounding code which is > nearby. Ok, found something: The table has 0.5 hardcoded instead of the correct (rounding-mode dependent) r. And the code in line 836 (and 858?) also.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #4 from Jerry DeLisle 2011-04-15 20:13:12 UTC --- OK I knew I was "looking" at it wrong. The formulas you mention we are using and are in write_float.def starting at line 798. The table is there as well. I have been exploring the code here but have not spotted it yet. The issue could either be in this formula implementation or in the rounding code which is nearby.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #3 from Thomas Henlich 2011-04-15 19:58:55 UTC --- (In reply to comment #2) > I am missing something here: > > "print "(RU,G15.2)", .991d0 > prints 1.00 but the expected result is 1.0 because 1 - r * 10**-2 < .991 with > r > = 1 because of UP rounding mode" > > We are asking for two decimal digits in g15.2 above so 1.00 looks right to me. No. The d in G editing describes the number of significant digits, not the number of decimal digits. Fortran 2008: 10.7.5.2.2 states clearly (first table in clause 4) that for a value which rounds to a value greater or equal to 1 and smaller than 10 the equivalent conversion is F(w-n).(d-1) and n blanks. Thus the number of significant digits is d, because 1 digit comes before the decimal separator and (d-1) digits after it. GFortran does it right in most cases, except the ones described in this bug: UP/DOWN rounding with values close to 1 (or other powers of 10) which would round differently if COMPATIBLE rounding was in effect.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #2 from Jerry DeLisle 2011-04-15 19:31:06 UTC --- I am missing something here: "print "(RU,G15.2)", .991d0 prints 1.00 but the expected result is 1.0 because 1 - r * 10**-2 < .991 with r = 1 because of UP rounding mode" We are asking for two decimal digits in g15.2 above so 1.00 looks right to me. I do see a problem with this: print "(RU,G15.1)", .991d0 print "(RU,G15.2)", .991d0 print "(RU,G15.3)", .991d0 print "(RU,G15.4)", .991d0 print "(RU,G15.5)", .991d0 Which gives: 1. <--This should be 1.0 I believe 1.00 0.991 0.9910 0.99100 On the rounding down side we have: print "(RD,G15.1)", .991d0 print "(RD,G15.2)", .991d0 print "(RD,G15.3)", .991d0 print "(RD,G15.4)", .991d0 print "(RD,G15.5)", .991d0 Gives: 0. <-- This should be 0.9 I believe 0.99 0.990 0.9909 0.99099 What do you think Thomas?
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.14 15:20:26 AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jerry DeLisle 2011-04-14 15:20:26 UTC --- Ok and thanks for the test cases, they really help with the details. I will work on this.