[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
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=gccview=revrev=194717 Log: PR fortran/55539 Fix regression in -fno-sign-zero. libgfortran ChangeLog: 2012-12-26 Janne Blomqvist j...@gcc.gnu.org PR fortran/55539 * io/write_float.def (output_float): Take into account decimal dot. testsuite ChangeLog: 2012-12-26 Janne Blomqvist j...@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
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.
[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
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
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.)
[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
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 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.)
[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
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
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=gccview=revrev=185433 (Rev. 185486, PR 52608 is a minor follow up, but not causing the problem.)
