public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output
@ 2012-11-29 22:11 anlauf at gmx dot de
2012-11-30 21:24 ` [Bug fortran/55539] " dominiq at lps dot ens.fr
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: anlauf at gmx dot de @ 2012-11-29 22:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate wrong formatted output
2012-11-29 22:11 [Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output anlauf at gmx dot de
@ 2012-11-30 21:24 ` dominiq at lps dot ens.fr
2012-11-30 21:48 ` [Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign burnus at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-11-30 21:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
2012-11-29 22:11 [Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output anlauf at gmx dot de
2012-11-30 21:24 ` [Bug fortran/55539] " dominiq at lps dot ens.fr
@ 2012-11-30 21:48 ` burnus at gcc dot gnu.org
2012-12-11 22:33 ` anlauf at gmx dot de
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-11-30 21:48 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
2012-11-29 22:11 [Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output anlauf at gmx dot de
2012-11-30 21:24 ` [Bug fortran/55539] " dominiq at lps dot ens.fr
2012-11-30 21:48 ` [Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign burnus at gcc dot gnu.org
@ 2012-12-11 22:33 ` anlauf at gmx dot de
2012-12-12 11:16 ` burnus at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: anlauf at gmx dot de @ 2012-12-11 22:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
2012-11-29 22:11 [Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output anlauf at gmx dot de
` (2 preceding siblings ...)
2012-12-11 22:33 ` anlauf at gmx dot de
@ 2012-12-12 11:16 ` burnus at gcc dot gnu.org
2012-12-15 16:36 ` jb at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-12-12 11:16 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
2012-11-29 22:11 [Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output anlauf at gmx dot de
` (3 preceding siblings ...)
2012-12-12 11:16 ` burnus at gcc dot gnu.org
@ 2012-12-15 16:36 ` jb at gcc dot gnu.org
2012-12-15 16:48 ` jb at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jb at gcc dot gnu.org @ 2012-12-15 16:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
2012-11-29 22:11 [Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output anlauf at gmx dot de
` (4 preceding siblings ...)
2012-12-15 16:36 ` jb at gcc dot gnu.org
@ 2012-12-15 16:48 ` jb at gcc dot gnu.org
2012-12-25 22:11 ` jb at gcc dot gnu.org
2012-12-25 22:22 ` jb at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jb at gcc dot gnu.org @ 2012-12-15 16:48 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
2012-11-29 22:11 [Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output anlauf at gmx dot de
` (5 preceding siblings ...)
2012-12-15 16:48 ` jb at gcc dot gnu.org
@ 2012-12-25 22:11 ` jb at gcc dot gnu.org
2012-12-25 22:22 ` jb at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jb at gcc dot gnu.org @ 2012-12-25 22:11 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
2012-11-29 22:11 [Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output anlauf at gmx dot de
` (6 preceding siblings ...)
2012-12-25 22:11 ` jb at gcc dot gnu.org
@ 2012-12-25 22:22 ` jb at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jb at gcc dot gnu.org @ 2012-12-25 22:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-12-25 22:22 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-29 22:11 [Bug fortran/55539] New: [4.8 Regression] -fno-sign-zero may generate wrong formatted output anlauf at gmx dot de
2012-11-30 21:24 ` [Bug fortran/55539] " dominiq at lps dot ens.fr
2012-11-30 21:48 ` [Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign burnus at gcc dot gnu.org
2012-12-11 22:33 ` anlauf at gmx dot de
2012-12-12 11:16 ` burnus at gcc dot gnu.org
2012-12-15 16:36 ` jb at gcc dot gnu.org
2012-12-15 16:48 ` jb at gcc dot gnu.org
2012-12-25 22:11 ` jb at gcc dot gnu.org
2012-12-25 22:22 ` jb at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).