Re: PATCH: HUGE_VAL should be Infinity

[Jeffrey A Law <law at redhat dot com>]

  In message <200010180419.AAA21005@hiauly1.hia.nrc.ca>you write:
  > > Another option (if fixing hugeval.c is a pain) is to move hugeval.c
  > > into the ieee directory which makes it clearer that it depends on
  > >  ieee754 arithmetic.
  > 
  > That's where it is already.
My bad.  Sorry.

  > I spent time on it because hppa hardware
  > nominally has an ieee compatible floating unit.
Correct, except as you note, the lack of an fneg instruction on PA1.0 and
PA1.1 chips makes it impossible to perform an efficient negation operation.

  > sent the other day fixes the compare tests.  The mzero2 tests fail because
  > negation of +0. yields +0.  This apparently violates the above ieee
  > standard.
Correct.  It is a violation.


  > However, it could be a difference in opinion between HP and Intel on the
  > standard as even relatively recent HP gear still exhibits the same problem.
Nyet.  Recent HP chips (all PA2.0 variants) have fneg which provides an
ieee compliant negation.

I really don't like the idea of hacking up mzero to avoid the problem with
PA1.0 and PA1.1 chips.

If we really want to DTRT we would provide a -mieee flag for the PA port
which would do negations in an ieee compliant way (specifically by twiddling
the sign bit).  The testsuite knows how to add -mieee when performing the
ieee tests.

That way people who really need strict ieee conformance on PA1.x harware
can get it via -mieee and the rest of the world that doesn't care about this
corner issue doesn't have to pay the speed penalty and our testsuites will
just DTRT.


jeff