http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49188
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-05-27
12:31:21 UTC ---
(In reply to comment #0)
> This fno-sign-zero behaviour is not according to the Fortran standard
Well, -fno-sign-zero is definitely not according to the Fortran 90+ standard as
one there has signed zero. Fortran 77 does not really say anything about signed
zeros, thus, some programs assume that there is only one zero, which is
positive. However, I think according to the Fortran 77 standard, a negative
zero is also a valid implementation choice.
> ("a minus sign if the internal value is negative") including F77 which is
> explicitly mentioned in the documentation.
For cross-reference the quote is from "13.5.9.2.1 F_Editing" at
ftp://ftp.nag.co.uk/sc22wg5/ARCHIVE/Fortran77.html
I think the current behavior is OK. For programs, which do not handle negative
zeros, one should never print a minus - independent whether the internal value
is exactly zero or only after truncation. If I run your program (w/o "rc,")
with g77, I get:
0.0
Ditto with ifort (w/ and w/o "rc,", unless "-assume minus0"), pathf95 and
pgf90.
There are really programs - Fortran programs or post-processing programs, which
rely on not printing "-0.0" and on the non-conforming SIGN behavior (with
regards to negative zeros). Thus, it does not really matter whether
-fno-sign-zero breaks the Fortran standard or not, if programs rely on it and
if gfortran conforms to the standard by default.
