This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: HUGE_VAL should be Infinity
- To: law at redhat dot com
- Subject: Re: PATCH: HUGE_VAL should be Infinity
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Date: Thu, 30 Nov 2000 13:22:46 -0500 (EST)
- Cc: meissner at cygnus dot com, gcc-patches at gcc dot gnu dot org
My currently suggested fix for the hugeval and mzero tests is to make
them expected fails. The patch is here
<http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00615.html>.
> In message <200010180419.AAA21005@hiauly1.hia.nrc.ca>you write:
...
> > 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.
According to my tests, at least some PA1.1 chips have the fneg instruction.
I ran tests with it on the 735 that I have. However, probably some PA1.1
chips don't have it or the HP hardware engineers forgot to tell the software
folks about it (or maybe they noticed bugs in the implementation). Anyway,
the fneg on the 735 behaves the same as subtracting from 0. Thus, there
is no advantage in using it.
> > 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.
Wrong. I tried fneg on a C200 and again negation of +0. yielded +0. The
behaviour was identical to that of the 735. Thus, I don't believe that
all the new PA2.0 chips provide an ieee compliant negation. HP is usually
pretty good about this kind of thing which was why I wondered if there
was some debate about the standard.
> I really don't like the idea of hacking up mzero to avoid the problem with
> PA1.0 and PA1.1 chips.
Agreed.
> 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.
That's a good idea. Thus, if this enhancement were added, we would just need
the hugeval part of the patch refered to above.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)