[Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output

[Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output

[anlauf at gmx dot de]

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

             Bug #: 55539
           Summary: [4.8 Regression] -fno-sign-zero may generate wrong
                    formatted output
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: anlauf@gmx.de


The code

program gfcbug120
  implicit none
  real(4) :: x = -1.2e-3
  real(8) :: y = -1.2e-3
  print *, x, y
  print '(7f10.3)', x, y
end program gfcbug120

incorrectly prints

  -1.20000006E-03  -1.2000000569969416E-003
     0.001     0.001

with -fno-sign-zero; the correct result would be

  -1.20000006E-03  -1.2000000569969416E-003
    -0.001    -0.001

This works with 4.7.

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-11-30
     Ever Confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-11-30 21:23:44 UTC ---
Confirmed.
Revision 184852 (2012-03-03) is OK.
Revision 185504 (2012-03-18) is not.
However I did not spot any obvious culprit in this range.

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

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P4
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |jb at gcc dot gnu.org
   Target Milestone|---                         |4.8.0
            Summary|[4.8 Regression]            |[4.8 Regression]
                   |-fno-sign-zero may generate |-fno-sign-zero may generate
                   |wrong formatted output      |output with the wrong sign

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-11-30 21:47:55 UTC ---
Janne, I think it is due to your commit for PR 52434, PR 48878, PR 38199,
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185433

(Rev. 185486, PR 52608 is a minor follow up, but not causing the problem.)

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

[anlauf at gmx dot de]

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

--- Comment #3 from Harald Anlauf <anlauf at gmx dot de> 2012-12-11 22:33:21 UTC ---
(In reply to comment #2)

I played a little bit with the code and found that the
following patch appears to fix my problem:

Index: libgfortran/io/write_float.def
===================================================================
--- libgfortran/io/write_float.def      (revision 194417)
+++ libgfortran/io/write_float.def      (working copy)
@@ -492,7 +492,7 @@
   /* To format properly, we need to know if the rounded result is zero and if
      so, we set the zero_flag which may have been already set for
      actual zero.  */
-  if (i == ndigits)
+  if (i == ndigits && (digits[i] == '0' || digits[i] == '.'))
     {
       zero_flag = true;
       /* The output is zero, so set the sign according to the sign bit unless


Testcase:

  implicit none
  real              :: x = 0.5 + epsilon(0.)
  character(len=80) :: line
  print '(7f5.1)', x, -x
  write (line,'(2f5.1)') x, -x
  print '(A)', line
  if (line /= "  0.5 -0.5") call abort ()
  print '(7f5.0)', x, -x
  write (line,'(2f5.0)') x, -x
  print '(A)', line
  if (line /= "   1.  -1.") call abort ()
end


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.

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

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-12 11:16:33 UTC ---
(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):

"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\vect as those speci\fed
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.)

[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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot       |jb at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-12-15 16:36:08 UTC ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01011.html

Although Harald's patch fixed the issue for me as well, I opted for a slightly
different approach. The regression crept in because in the old code we had
removed the decimal point, whereas in the current code it may be included in
the string we're investigating.

[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\vect as those speci\fed
> 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.)

[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 #7 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-12-25 22:11:21 UTC ---
Author: jb
Date: Tue Dec 25 22:11:16 2012
New Revision: 194717

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194717
Log:
PR fortran/55539 Fix regression in -fno-sign-zero.

libgfortran ChangeLog:

2012-12-26  Janne Blomqvist  <jb@gcc.gnu.org>

    PR fortran/55539
    * io/write_float.def (output_float): Take into account decimal dot.

testsuite ChangeLog:

2012-12-26  Janne Blomqvist  <jb@gcc.gnu.org>

    PR fortran/55539
    * gfortran.dg/nosigned_zero_3.f90: New testcase.

Added:
    trunk/gcc/testsuite/gfortran.dg/nosigned_zero_3.f90
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/write_float.def

[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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-12-25 22:21:51 UTC ---
Fixed on trunk, closing.