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 eect 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.)