[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[ebay.20.tedlap at spamgourmet dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #51 from Lionel GUEZ ebay.20.tedlap at spamgourmet dot com 
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

[ebay.20.tedlap at spamgourmet dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #50 from Lionel GUEZ ebay.20.tedlap at spamgourmet dot com 
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

[jvdelisle at frontier dot com]

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 GUEZebay.20.tedlap at spamgourmet dot com  
 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #53 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

Jerry DeLisle jvdelisle at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #54 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[ebay.20.tedlap at spamgourmet dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

Lionel GUEZ ebay.20.tedlap at spamgourmet dot com changed:

   What|Removed |Added

 CC||ebay.20.tedlap at
   ||spamgourmet dot com

--- Comment #47 from Lionel GUEZ ebay.20.tedlap at spamgourmet dot com 
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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #49 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[jvdelisle at frontier dot com]

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 GUEZebay.20.tedlap at spamgourmet dot com  
 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #46 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #44 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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=gccview=revrev=173166
Log:
2011-04-29  Jerry DeLisle  jvdeli...@gcc.gnu.org
Janne Blomqvist  j...@gcc.gnu.org

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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #45 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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=gccview=revrev=173168
Log:
2011-04-29  Jerry DeLisle  jvdeli...@gcc.gnu.org

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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #43 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #40 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #41 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #42 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #37 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #38 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #39 from Tobias Burnus burnus at gcc dot gnu.org 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

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #31 from Tobias Burnus burnus at gcc dot gnu.org 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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #32 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #33 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #34 from Tobias Burnus burnus at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #35 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #36 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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=gccview=revrev=172753
Log:
2011-04-19  Jerry DeLisle  jvdeli...@gcc.gnu.org

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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #23 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #22 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #24 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #26 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #25 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

Mikael Morin mikael at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #27 from Mikael Morin mikael at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #28 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #29 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #30 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #16 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #17 from Thomas Henlich thenlich at users dot sourceforge.net 
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).

Re: [Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[Jerry DeLisle]

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

[jvdelisle at frontier dot com]

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.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #19 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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=gccview=revrev=172634
Log:
2011-04-17  Jerry DeLisle  jvdeli...@gcc.gnu.org

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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #20 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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=gccview=revrev=172635
Log:
2011-04-17  Jerry DeLisle  jvdeli...@gcc.gnu.org

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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #21 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #8 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[jvdelisle at frontier dot com]

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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #10 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #11 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #12 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #13 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #14 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #15 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #3 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #5 from Thomas Henlich thenlich at users dot sourceforge.net 
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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

--- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org 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

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602

Jerry DeLisle jvdelisle at gcc dot gnu.org 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 jvdelisle at gcc dot gnu.org 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.