Re: [patch, libgfortran] PR48906 Wrong rounding results with -m32

2011-06-14 Thread Thomas Henlich 
On Tue, Jun 14, 2011 at 06:51, jerry DeLisle jvdeli...@charter.net wrote:
 It should be easy to implement:

 After the switch between F and E editing, we just need to shift the
 decimal point and decrement the exponent. No new rounding is required,
 because we keep the number of significant digits.


 OK, after a little bit of experimentation, I have arrived at the updated
 patch attached.

 This has been regression tested and passes all test cases I am aware of.  I
 also have included a new test case gcc/testsuite/gfortran.dg/fmt_g.f90.

 OK for trunk?

I have reviewed your patch, and I noticed that you placed the
digit-shifting code quite at the top of output_float(), where the
final value of e is not even known. Due to rounding, e can be modified
after this point, so your code will generate invalid output in some
cases, for example:

print (-2PG0), nearest(0.1d0, -1.0d0) ! 1.E+001
expected .002E+001

Please put the code where at belongs, after the switch between F and E
editing (based on the final value of e).

The same applies to the scale factor in general, e.g.

print (-2pg12.3), 0.096! 1.00E+01 expected 0.001E+02
print (-1pg12.3), 0.0996   ! 1.00E+00 expected 0.010E+01
print (-2pg12.3), 0.09996  ! 1.00E+01 expected 0.100
print (-1pg12.3), 0.09996  ! 1.00E+00 expected 0.100
print (1pg12.3),  0.06 ! 1.000E-01 expected 0.100
print (2pg12.3),  0.06 ! 10.00E-02 expected 0.100
print (-2pg12.3),  999.6  ! 0.100E+04 expected 0.001E+06
print (-1pg12.3),  999.6  ! 0.100E+04 expected 0.010E+05
print (1pg12.3),  999.6  ! 0.100E+04 expected 9.996E+02
print (2pg12.3),  999.6  ! 0.100E+04 expected 99.96E+01

Please revise your code to fix this. A working approach I have outlined in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906#c28
and an (alpha) implementation is here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906#c31

Thomas

Re: [patch, libgfortran] PR48906 Wrong rounding results with -m32

2011-06-11 Thread Thomas Henlich 
 I don't agree with this; with the patch we now output 10 significant
 digits, whereas 9 is sufficient for a binary-ascii-binary roundtrip.
 So please retain the reduce d by one when E editing is used thing
 for list format and G0. This is just a side effect of using 1PGw.d
 format for list format and G0 in order to avoid duplicating code, but
 we don't need to follow this particular craziness that is due to how
 the scale factor is specified in the standard.

I hadn't noticed this, but I agree with Janne.

It should be easy to implement:

After the switch between F and E editing, we just need to shift the
decimal point and decrement the exponent. No new rounding is required,
because we keep the number of significant digits.

Re: [patch, libgfortran] PR48906 Wrong rounding results with -m32

2011-06-11 Thread Thomas Henlich 
On Sat, Jun 11, 2011 at 14:41, jerry DeLisle jvdeli...@charter.net wrote:
 This was established as solution to PR48488 where we had two choices for
 selecting the significant digits. Nine significant digits was established as
 a requirement to guarantee round trip in all cases. The char4_iunit_1.f03
 test case was revised because after we corrected the formatting in PR48906,
 it started to fail and I observed the test case was looking for the wrong
 number of significant digits.

 Based on this, I would suggest we leave it as I have it, which is correct.

I'm afraid it's not.

1.23450002E-06 has nine significant digits. That's how it should be.

We don't want 1PG16.9E2 editing for list-directed and G0,
but G16.9E2 for the F editing range and 1PE16.8E2 editing for the E range.

This is to make sure the result always has nine significant digits,
whether in the F or E range.