This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch 9/N][PA] convert to fma
On Sat, 13 Nov 2010, H.J. Lu wrote:
> > Yes, -(a*b) = (-a)*b. ?I suppose you are correct that we could wind up with
> > a difference between -QNaN (first case) and +QNaN (second case). ?But unlike
> > caring for the sign of zero, there's nothing in gcc that seeks to preserve
> > the sign of NaNs.
When either an input or result is NaN, this standard does not
interpret the sign of a NaN. Note, however, that operations on bit
strings -- copy, negate, abs, copySign -- specify the sign bit of a
NaN result, sometimes based upon the sign bit of a NaN operand. The
logical predicate totalOrder is also affected by the sign bit of a NaN
operand. For all other operations, this standard does not specify the
sign bit of a NaN result, even when there is only one input NaN, or
when the NaN is produced from an invalid operation.
(IEEE 754-2008, section 6.3.)
Attempting to preserve the signs of NaNs for the operations abs and negate
where they matter is why the MIPS back end does not use abs and neg
instructions unless -ffinite-math-only. There would be a use for a
-fno-signed-nans option like -fno-signed-zeros, which would serve to
enable those MIPS instructions at least.
> > I'll also say that this is the representation that we've been using for all
> > of the other ports.
>
> That is true. GCC doesn't even preserve kinds (Q vs S) of NaNs on
> x86 with SSE FP math.
Non-preservation of the kind of NaN (if it should otherwise be preserved
for IEEE semantics) should be conditioned on HONOR_SNANS (mode). (The
documentation of -fsignaling-nans does warn that not everything that
should be conditioned on it necessarily is.)
--
Joseph S. Myers
joseph@codesourcery.com