[Bug libfortran/48906] Wrong rounding results with -m32

["thenlich at users dot sourceforge.net" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #26 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-06-06 12:27:38 UTC ---
(In reply to comment #25)
> My confusion seems to be when scale factor is to be ignored and when not,  I 
> will give the standard another read.

As it happens, you're not the only one to find (this part of) the Fortran
standard confusing and buggy, so if all goes as planned there will be a
rewrite:

---------------------------------------------------------------------
                                                    11-xxx
To: J3
From: John Reid and Thomas Henlich
Subject: Interp: G editing for reals
Date: 2011 June 5

---------------------------------------------------------------------

NUMBER: F08/xxxx
TITLE: G editing for reals
KEYWORDS: format, G editing
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

1. Gw.d editing for a real value that is in the range (0.1,10**d) and 
is not near an integer power of 10 uses F editing to produce exactly 
the same value as 0PEw.d editing would produce. For values in this 
range that are near an integer power of 10, is it intended that F 
editing be used to produce exactly the same value as 0PEw.d editing 
would produce? 

The rules in 10.7.5.2.2 usually have this effect, but the following
examples illustrate exceptions for rounding UP and to ZERO.
  i. 
     print "(ru,g11.2)", -9.95 
  or
     print "(rz,g11.2)", -9.95 
  Here, 0PE11.2 editing would produce the value -0.99E+01, which can be 
  represented as -9.9. However, the standard requires F7.0 to be used, 
  which gives the result -9. Note that the standard requires
     print "(rd,g11.2)", 9.95
  and
     print "(rz,g11.2)", 9.95
  to give the result 9.9. 

  ii.
     print "(ru,0p,g11.2)", -99.5
  The standard requires 0PE11.2 editing to be used, which gives 
  -0.99E+02. This is representable as -99.

  iii. 
     print "(ru,0p,g11.2)", 99.
  The standard requires 0PE11.2 editing to be used, which gives 
  0.99E+02. This is representable as 99.


2. COMPATIBLE and NEAREST modes of rounding differ only when the two
nearest representable values are equidistant from the given value. The
similarity appears not to be represented in the second table. What is
meant by "if the higher value is even"?

3. Why is no account taken of the effects when PROCESSOR_DEFINED 
rounding is in effect? 


ANSWER:

1. Yes, this was the intention and it would be clearer for the standard
to state this directly. It would also be easier for implementers to 
implement. 

2. If the standard is rewritten as proposed in the first question, these
further problems would be resolved. 

3. If the standard is rewritten as proposed in the first question, 
PROCESSOR_DEFINED rounding would be covered. 

EDITS to 10-007r1:

[258:14-20] In 10.7.5.2.2, replace paragraph 4 by
"Otherwise, the method of representation in the output field depends
on the internal value being edited. Let N be the value that would be
output with 0PEw.dEe editing and let s be its exponent part unless N 
is identically 0 in which case let s be 1. Let k be the scale factor 
(10.8.5). Let b be a blank. For Gw.d editing, if s lies in the range
0 <= s <= d, F(w-4).(d-s),4('b') editing is used to represent N in the
output field; otherwise, kPEw.d editing is used to represent the
internal value. For Gw.dEe editing, if s lies in the range 0 <= s <= d, 
F(w-n).(d-s),n('b') editing where n=e+2 is used to represent N in the 
output field; otherwise, kPEw.dEe editing is used to represent the 
internal value." 


SUBMITTED BY: John Reid and Thomas Henlich 

HISTORY: 11-xxx    m195  Submitted

------------------------------------------------------------------------