This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
Jeffrey A Law <law@upchuck.cygnus.com> writes:
|> In message <36CC7D27.A8200D2C@interix.com>you write:
|> > I note that regression ieee/mzero2.c fails on many (most, all?)
|> > of the alphas and hppa boxes. It appears that the cause is
|> > not compiling with synchronous traps (trapb on alpha) instructions
|> > enabled. (Probably the same cause on hppa, which has a similar
|> > architecture in this regard.) (Certainly turning on traps makes
|> > it behave better, altho I havn't bothered yet to find the minimum
|> > necessary setting.)
|> No, the PA's cause is different and has nothing to do with the FP exception
|> model in use.
|>
|> The problem is -1.0 * +0.0 is turned into -(+0.0).
|>
|> A negate instruction on the PA1.x machines is implemented by an fsub
|> instruction -- fsub %fr0,src,target
|>
|> %fr0 always holds +0.0
|>
|> +0.0 - +0.0 = +0.0 which has a different bit pattern than -0.0 which causes
|> the abort.
|>
|> One could certainly ask whether or not it is safe for the compiler
|> to make the transformation from -1.0 * x to -(x). One could also
|> question whether or not the PA port should expose an fneg instruction
|> using fsub.
|>
|> I'll let the IEEE experts chime in before I try to fix this :-)
See the current C9X draft, section F.8.2 (Expression transformations):
-x <-> 0 - x The expressions -x and 0 - x are
not equivalent if x is +0,
because -(+0) yields -0, but 0 -
(+0) yields +0 (unless rounding
is downward).
Thus this transformation is not safe.
--
Andreas Schwab "And now for something
schwab@issan.cs.uni-dortmund.de completely different"
schwab@gnu.org