[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign

[jb at gcc dot gnu.org]

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

--- Comment #6 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-12-15 16:47:44 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Strangely enough I needed to add some epsilon to 0.5 so that
> > the second test passes, because the exact value 0.5 appears
> > to get rounded down to 0 in formatted output.
> 
> That should depend on the rounding mode; you have the choice between 
> RD (round down), RC (compatible), RN (nearest), RP (processor dependent), RU
> (round up), RZ (round towards zero).
> 
> The default ("RD")  in gfortran is NEAREST, which has to match IEEE 754-1985 
> (alias IEC 60559:1989), namely (cf. Note 10.14 in Fortran 2008):

Actually, for processor dependent or unspecified (default) rounding,
libgfortran does not do any rounding itself, but rather uses the snprintf()
generated digits directly; A large part of the r185433 patch was figuring out
the correct number of digits so that we could skip the libgfortran rounding
step. 

That being said, a snprintf() which claims conformance to IEEE 754 should by
default provide round to nearest, ties to even rounding behavior. 

> "On processors that support IEEE rounding on conversions, the I/O rounding
> modes COMPATIBLE and NEAREST will produce the same results except when the
> datum is halfway between the two representable values. In that case, NEAREST
> will pick the even value, but COMPATIBLE will pick the value away from zero.
> The I/O rounding modes UP, DOWN, and ZERO have the same e
ect as those speci
ed
> in IEC 60559:1989 for round toward +oo, round toward -oo, and round toward 0,
> respectively."
> 
> And 0.5 rounded to even rounds down to "0" and not up to "1". (Seemingly,
> decimal "0.5" is exactly representable in binary FP while decimal "0.1" isn't.)