PATCH: HUGE_VAL should be Infinity

PATCH: HUGE_VAL should be Infinity

[John David Anglin]

Under HP-UX 10.20 (and probably on other systems), HUGE_VAL is defined as
1.7976931348623157e+308 (same as DBL_MAX).  This is the maximum normalized
value for a double.  However, HUGE_VAL should actually be defined as
Infinity according to the hugeval.c testsuite program.

The following technique for defining HUGE_VAL was derived from that used
in the hugeval.c testsuite program and the linux bits/hugeval.h header.
It is considerably simpler than that used in bits/hugeval.h.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2000-10-14  J. David Anglin  <dave@hiauly1.hia.nrc.ca>

	* inclhack.def (hpux10_hugeval): New fix to correct definition
	of HUGE_VAL under HP-UX 10.X.

--- inclhack.def.orig	Fri Sep 29 14:23:52 2000
+++ inclhack.def	Mon Oct 16 12:22:29 2000
@@ -1569,6 +1571,27 @@
 };
 
 
+/*
+ * HUGE_VAL should be Infinity when doing IEEE math.  HP-UX 10.X uses the
+ * wrong value (DBL_MAX).  This fix should come after math_huge_val_ifndef.
+ */
+fix = {
+    hackname = math_huge_val_inf;
+    files    = math.h;
+    select    = "^#[ \t]*define[ \t]*HUGE_VAL[ \t]*1[.]7976931348623157e[+]308";
+
+    c_fix     = format;
+    c_fix_arg = "#  ifdef __STDC__\n"
+		"     static const double __huge_val = 1.0 / 0.0;\n"
+		"#  else\n"
+		"     static double __huge_val = 1.0 / 0.0;\n"
+		"#  endif\n"
+		"#  define HUGE_VAL (__huge_val)";
+
+    test_text = "# define\tHUGE_VAL 1.7976931348623157e+308";
+};
+
+
 /*
  * Fix nested comments in Motorola's <limits.h> and <sys/limits.h>
  */

Re: PATCH: HUGE_VAL should be Infinity

[Jeffrey A Law]

  In message < 200010161746.NAA09258@hiauly1.hia.nrc.ca >you write:
  > Under HP-UX 10.20 (and probably on other systems), HUGE_VAL is defined as
  > 1.7976931348623157e+308 (same as DBL_MAX).  This is the maximum normalized
  > value for a double.  However, HUGE_VAL should actually be defined as
  > Infinity according to the hugeval.c testsuite program.
  > 
  > The following technique for defining HUGE_VAL was derived from that used
  > in the hugeval.c testsuite program and the linux bits/hugeval.h header.
  > It is considerably simpler than that used in bits/hugeval.h.
  > 
  > Dave
  > -- 
  > J. David Anglin                                  dave.anglin@nrc.ca
  > National Research Council of Canada              (613) 990-0752 (FAX: 952-6
  > 605)
  > 
  > 2000-10-14  J. David Anglin  <dave@hiauly1.hia.nrc.ca>
  > 
  > 	* inclhack.def (hpux10_hugeval): New fix to correct definition
  > 	of HUGE_VAL under HP-UX 10.X.
Don't you also need to fix HUGE_VALF?

jeff

Re: PATCH: HUGE_VAL should be Infinity

[John David Anglin]

>   > 2000-10-14  J. David Anglin  <dave@hiauly1.hia.nrc.ca>
>   > 
>   > 	* inclhack.def (hpux10_hugeval): New fix to correct definition
>   > 	of HUGE_VAL under HP-UX 10.X.
> Don't you also need to fix HUGE_VALF?

I have no objection to adding it.  However, it is not defined under
10.20, so I presumed that code had to be prepared to do without.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PATCH: HUGE_VAL should be Infinity

[Michael Meissner]

On Mon, Oct 16, 2000 at 07:35:27PM -0600, Jeffrey A Law wrote:
>   In message < 200010161746.NAA09258@hiauly1.hia.nrc.ca >you write:
>   > Under HP-UX 10.20 (and probably on other systems), HUGE_VAL is defined as
>   > 1.7976931348623157e+308 (same as DBL_MAX).  This is the maximum normalized
>   > value for a double.  However, HUGE_VAL should actually be defined as
>   > Infinity according to the hugeval.c testsuite program.
>   > 
>   > The following technique for defining HUGE_VAL was derived from that used
>   > in the hugeval.c testsuite program and the linux bits/hugeval.h header.
>   > It is considerably simpler than that used in bits/hugeval.h.
>   > 
>   > Dave
>   > -- 
>   > J. David Anglin                                  dave.anglin@nrc.ca
>   > National Research Council of Canada              (613) 990-0752 (FAX: 952-6
>   > 605)
>   > 
>   > 2000-10-14  J. David Anglin  <dave@hiauly1.hia.nrc.ca>
>   > 
>   > 	* inclhack.def (hpux10_hugeval): New fix to correct definition
>   > 	of HUGE_VAL under HP-UX 10.X.
> Don't you also need to fix HUGE_VALF?

I suspect there is no HUGE_VALF, since that wasn't in the 1989 standard IIRC
(it is in the 99 standard, since that standard now has float and long double
math functions that could return HUGE_VAL{F,L}).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: PATCH: HUGE_VAL should be Infinity

[John David Anglin]

> >   > 2000-10-14  J. David Anglin  <dave@hiauly1.hia.nrc.ca>
> >   > 
> >   > 	* inclhack.def (hpux10_hugeval): New fix to correct definition
> >   > 	of HUGE_VAL under HP-UX 10.X.
> > Don't you also need to fix HUGE_VALF?
> 
> I suspect there is no HUGE_VALF, since that wasn't in the 1989 standard IIRC
> (it is in the 99 standard, since that standard now has float and long double
> math functions that could return HUGE_VAL{F,L}).

Having thought a little more about this, I believe the change is wrong as it
will make the define in math.h inconsistent with the system's existing math
library.  Thus, the patch should not be applied.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PATCH: HUGE_VAL should be Infinity

[Jeffrey A Law]

  In message < 200010170201.WAA10174@hiauly1.hia.nrc.ca >you write:
  > >   > 2000-10-14  J. David Anglin  <dave@hiauly1.hia.nrc.ca>
  > >   > 
  > >   > 	* inclhack.def (hpux10_hugeval): New fix to correct definition
  > >   > 	of HUGE_VAL under HP-UX 10.X.
  > > Don't you also need to fix HUGE_VALF?
  > 
  > I have no objection to adding it.  However, it is not defined under
  > 10.20, so I presumed that code had to be prepared to do without.
Possibly.  I found it on linux and hpux11 when investigating how they
handled this issue.

Based on Michael's comments, I'll consider HUGE_VALF a non-issue.

jeff

Re: PATCH: HUGE_VAL should be Infinity

[Jeffrey A Law]

  In message < 200010170458.AAA23638@hiauly1.hia.nrc.ca >you write:
  > Having thought a little more about this, I believe the change is wrong as i
  > will make the define in math.h inconsistent with the system's existing math
  > library.  Thus, the patch should not be applied.
Excellent point.

I guess the "fix" is to upgrade to hpux11 where this situation is handled
more gracefully.  FWIW, I do most of my hpux work on hpux11 now.

jeff

Re: PATCH: HUGE_VAL should be Infinity

[John David Anglin]

>   In message < 200010170458.AAA23638@hiauly1.hia.nrc.ca >you write:
>   > Having thought a little more about this, I believe the change is wrong as i
>   > will make the define in math.h inconsistent with the system's existing math
>   > library.  Thus, the patch should not be applied.
> Excellent point.
> 
> I guess the "fix" is to upgrade to hpux11 where this situation is handled
> more gracefully.  FWIW, I do most of my hpux work on hpux11 now.

After thinking about this overnight, I beieve the hugeval.c test should be
changed because the second half is not a compiler test.  It checks whether
the definition of HUGE_VAL is +Infinity.  The linux math.h header states
that HUGE_VAL is +Infinity on all IEEE754 machines.  However, this appears
not to be the case.  In any case, systems predating the standard or without
ieee floating point will fail the hugeval test.  Since I don't think
compiler tests should fail when there is nothing wrong with the compiler,
I will try to come up with a test fix.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PATCH: HUGE_VAL should be Infinity: hugeval.c PATCH

[John David Anglin]

>   In message < 200010170458.AAA23638@hiauly1.hia.nrc.ca >you write:
>   > Having thought a little more about this, I believe the change is wrong as i
>   > will make the define in math.h inconsistent with the system's existing math
>   > library.  Thus, the patch should not be applied.
> Excellent point.
> 
> I guess the "fix" is to upgrade to hpux11 where this situation is handled
> more gracefully.  FWIW, I do most of my hpux work on hpux11 now.

Here is a hack to the hugeval.c test for review.  It should now "work"
on some non IEEE systems.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2000-10-17  J. David Anglin  <dave@hiauly1.hia.nrc.ca>

	* hugeval.c: Revise so it doesn't fail on all non IEEE754 systems.

--- gcc.c-torture/execute/ieee/hugeval.c.orig	Fri Jul 21 22:46:24 2000
+++ gcc.c-torture/execute/ieee/hugeval.c	Tue Oct 17 18:45:16 2000
@@ -3,24 +3,48 @@
 static const double zero =  0.0;
 static const double pone =  1.0;
 static const double none = -1.0;
+/* Exclude systems that don't support infinity. */
+#if !defined(__vax__)
 static const double pinf =  1.0 / 0.0;
 static const double ninf = -1.0 / 0.0;
+#endif
+static double phuge, nhuge;
 
 int
 main ()
 {
+#if !defined(__vax__)
   if (pinf != pone/zero)
     abort ();
 
   if (ninf != none/zero)
     abort ();
+#endif
 
 #ifdef HUGE_VAL
-  if (HUGE_VAL != pinf)
-    abort ();
+  /* Generate positive and negative huge values and compare to +Infinity
+   * and -Infinity.  With luck, this will identify machines with an
+   * IEEE754 compatible math library. */
+  for (phuge = exp (1.0e+30); phuge < HUGE_VAL; phuge = exp (phuge));
+  nhuge = log (zero);
+#if !defined(__vax__)
+  if ((phuge == pinf) && (nhuge == ninf))
+    {
+      if (HUGE_VAL != pinf)
+        abort ();
 
-  if (-HUGE_VAL != ninf)
-    abort ();
+      if (-HUGE_VAL != ninf)
+        abort ();
+    }
+  else
+#endif
+    {
+      if (HUGE_VAL != phuge)
+        abort ();
+
+      if (-HUGE_VAL != nhuge)
+        abort ();
+    }
 #endif
 
   exit (0);

Re: PATCH: HUGE_VAL should be Infinity

[Jeffrey A Law]

  In message < 200010171851.OAA15821@hiauly1.hia.nrc.ca >you write:
  > >   In message < 200010170458.AAA23638@hiauly1.hia.nrc.ca >you write:
  > >   > Having thought a little more about this, I believe the change is wron
  > g as i
  > >   > will make the define in math.h inconsistent with the system's existin
  > g math
  > >   > library.  Thus, the patch should not be applied.
  > > Excellent point.
  > > 
  > > I guess the "fix" is to upgrade to hpux11 where this situation is handled
  > > more gracefully.  FWIW, I do most of my hpux work on hpux11 now.
  > 
  > After thinking about this overnight, I beieve the hugeval.c test should be
  > changed because the second half is not a compiler test.  It checks whether
  > the definition of HUGE_VAL is +Infinity.  The linux math.h header states
  > that HUGE_VAL is +Infinity on all IEEE754 machines.  However, this appears
  > not to be the case.  In any case, systems predating the standard or without
  > ieee floating point will fail the hugeval test.  Since I don't think
  > compiler tests should fail when there is nothing wrong with the compiler,
  > I will try to come up with a test fix.
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.
jeff

Re: PATCH: HUGE_VAL should be Infinity

[John David Anglin]

>   > After thinking about this overnight, I beieve the hugeval.c test should be
>   > changed because the second half is not a compiler test.  It checks whether
>   > the definition of HUGE_VAL is +Infinity.  The linux math.h header states
>   > that HUGE_VAL is +Infinity on all IEEE754 machines.  However, this appears
>   > not to be the case.  In any case, systems predating the standard or without
>   > ieee floating point will fail the hugeval test.  Since I don't think
>   > compiler tests should fail when there is nothing wrong with the compiler,
>   > I will try to come up with a test fix.
> 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.
> jeff

That's where it is already.  I spent time on it because hppa hardware
nominally has an ieee compatible floating unit.  Previously, most of the
ieee tests failed under hpux 10.20.  The unordered compare patch that I
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.
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.

Take a look at the patch for hugeval.c which I sent.  It still does the same
tests on ieee754 machines and doesn't fail under hpux 10.20.

It would be nice if the ieee tests didn't run on non ieee machines.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PATCH: HUGE_VAL should be Infinity -- Yet another solution

[John David Anglin]

>   > ieee floating point will fail the hugeval test.  Since I don't think
>   > compiler tests should fail when there is nothing wrong with the compiler,
>   > I will try to come up with a test fix.
> 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.

The enclosed patch changes the hugeval and mzero FAILs under hpux 9.X/10.X
to XFAILs except for the one '-fssa' compilation FAIL.  I think this is
a better solution than hacking hugeval.c  The previous hugeval.c patch
should be destroyed.

The patch has been tested under hpux 10.20.  With my compare patch and
this one, here is the summary for the ieee tests:

FAIL: ./gcc.c-torture/execute/ieee/fp-cmp-3.c compilation,  -O3 -fssa

                === gcc Summary for unix ===

# of expected passes            191
# of unexpected failures        1
# of expected failures          13
# of unresolved testcases       1

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2000-10-18  J. David Anglin  <dave@hiauly1.hia.nrc.ca>

	* hugeval.x: New.  Execution is expected to fail under hpux 9.X
	and 10.X because HUGE_VAL is DBL_MAX instead of +Infinity.
	* mzero2.x: Execution is expected to fail except at -O0 on hppa
	targets because negation of +0. yields +0.  -0. is expected.

--- gcc.c-torture/execute/ieee/hugeval.x.orig	Wed Oct 18 13:51:17 2000
+++ gcc.c-torture/execute/ieee/hugeval.x	Wed Oct 18 15:01:21 2000
@@ -0,0 +1,10 @@
+# This test fails under hpux 9.X and 10.X because HUGE_VAL is DBL_MAX
+# instead of +Infinity.
+
+global target_triplet
+if { [istarget "hppa*-*-hpux9*"] || [istarget "hppa*-*-hpux10*"] } {
+      set torture_execute_xfail "$target_triplet"
+}
+
+return 0
+
--- gcc.c-torture/execute/ieee/mzero2.x.orig	Sat Sep  4 11:09:14 1999
+++ gcc.c-torture/execute/ieee/mzero2.x	Wed Oct 18 16:35:27 2000
@@ -1,6 +1,22 @@
 # freebsd sets up the fpu with a different precision control which causes
 # this test to "fail".
 if { [istarget "i?86-*-freebsd*"] } {
-	set torture_execute_xfail "i?86-*-freebsd*"
+    set torture_execute_xfail "i?86-*-freebsd*"
+}
+
+# This test fails on hppa hardware in the evaluation of -1.00 * pzero at
+# all but -O0 because the multiply is converted to a negation.  Floating point
+# negation is implemented as a subtract from zero rather than a xor of the
+# sign bit on parisc machines.  As a result, -(+0.) = +0.  The expected
+# IEEE754 result is -0.
+if { [istarget "hppa*-*-*"] } {
+    set torture_eval_before_execute {
+        set compiler_conditional_xfail_data {
+            "hppa fp negation violates ieee754 standard" \
+            "hppa*-*-*" \
+            { "-O1" "-O2" "-O3*" "-Os" } \
+            { "" }
+        }
+    }
 }
 return 0

Re: PATCH: HUGE_VAL should be Infinity

[Jeffrey A Law]

  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

Re: PATCH: HUGE_VAL should be Infinity

[John David Anglin]

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)

Re: PATCH: HUGE_VAL should be Infinity

[Michael Meissner]

On Thu, Nov 30, 2000 at 01:22:46PM -0500, John David Anglin wrote:
> 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.

Or possibly HP/UX catches the unimplemented instruction trap and simulates the
unimplemented instruction, and then restarts the program.  Obviously if that is
the case, you don't want the compiler doing this for performance intensive
code.  I remember UNIX V6 doing this on a PDP-11/40 to emulate the 11/45
floating point, and being able to tell from the front console's blinking lights
when somebody was doing a stat package.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: PATCH: HUGE_VAL should be Infinity

[John David Anglin]

> > 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.
> 
> Or possibly HP/UX catches the unimplemented instruction trap and simulates the
> unimplemented instruction, and then restarts the program.  Obviously if that is

A quick test and you are correct.  HP/UX 10.20 emulates fneg when required.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: PATCH: HUGE_VAL should be Infinity

[Jeffrey A Law]

  In message < 200012041925.OAA06848@hiauly1.hia.nrc.ca >you write:
  > 2000-11-30  J. David Anglin  <dave@hiauly1.hia.nrc.ca>
  > 
  > 	* hugeval.x: New.  Execution is expected to fail under hpux 9.X
  > 	and 10.X because HUGE_VAL is DBL_MAX instead of +Infinity.
Thanks.  Installed.

jeff

Re: PATCH: HUGE_VAL should be Infinity

[Jeffrey A Law]

  In message < 200012041925.OAA06848@hiauly1.hia.nrc.ca >you write:
  > I am planning to implement ieee compatible negdf2 and negsf2 insns for
  > PA1.X machines.  It looked like multiplaction by -1 would be the most
  > efficient implementation since twiddling the sign bit of a floating
  > pointer register appears to involve copying to a general register via
  > memory and back again.  Multiplaction also looks simpler.  If Jeff can
  > recall whether or not there are corner effects with the multiplication
  > method it would be useful.
Found it.  fneg is non-arithmetic and does not cause an invalid operation
exception when a NaN is negated.

fmul is arithmetic and will cause exceptions.  Basically using any kind
of arithmetic insn to implement fneg loses in some form or another.


jeff

Re: PATCH: HUGE_VAL should be Infinity

[John David Anglin]

> On Thu, Nov 30, 2000 at 11:19:21PM -0700, Jeffrey A Law wrote:
> > 
> >   In message <200011302016.PAA28575@hiauly1.hia.nrc.ca>you write:
> >   > The fneg instruction on PA2.0 gear does negate +0. correctly.  Thus, there
> >   > is only a problem with PA1.0 and PA1.1 hardware which uses fsub.  The HP
> >   > compiler doesn't have the problem since it multiplies by -1. instead.
> > I think there was a case where that's not 100% valid either, though I think
> > it would be closer to conforming behavior than fsub.
> > 
> > FWIW, it may be the case that PA1.0 had fneg -- I don't have my manuals
> > handy, but there were a few instructions in PA1.0 that got removed.
> 
> FWIW, FNEG is not in my 1989 manual, which I think is PA1.1.

Last week, I had concluded that hpux 10.20 emulates fneg on my PA1.1 machine
(a 735).

I am planning to implement ieee compatible negdf2 and negsf2 insns for
PA1.X machines.  It looked like multiplaction by -1 would be the most
efficient implementation since twiddling the sign bit of a floating
pointer register appears to involve copying to a general register via
memory and back again.  Multiplaction also looks simpler.  If Jeff can
recall whether or not there are corner effects with the multiplication
method it would be useful.

I have separated out a patch to make the hugeval test an expected failure
under HP-UX 9 and 10.  As far as I can seen, there is no way to fix this
problem under these OS's because their math libraries are inconsistent
with the current IEEE definition of HUGE_VAL.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2000-11-30  J. David Anglin  <dave@hiauly1.hia.nrc.ca>

	* hugeval.x: New.  Execution is expected to fail under hpux 9.X
	and 10.X because HUGE_VAL is DBL_MAX instead of +Infinity.

--- gcc.c-torture/execute/ieee/hugeval.x.orig	Wed Oct 18 13:51:17 2000
+++ gcc.c-torture/execute/ieee/hugeval.x	Wed Oct 18 15:01:21 2000
@@ -0,0 +1,10 @@
+# This test fails under hpux 9.X and 10.X because HUGE_VAL is DBL_MAX
+# instead of +Infinity.
+
+global target_triplet
+if { [istarget "hppa*-*-hpux9*"] || [istarget "hppa*-*-hpux10*"] } {
+      set torture_execute_xfail "$target_triplet"
+}
+
+return 0
+

Re: PATCH: HUGE_VAL should be Infinity

[Michael Meissner]

On Thu, Nov 30, 2000 at 11:19:21PM -0700, Jeffrey A Law wrote:
> 
>   In message <200011302016.PAA28575@hiauly1.hia.nrc.ca>you write:
>   > The fneg instruction on PA2.0 gear does negate +0. correctly.  Thus, there
>   > is only a problem with PA1.0 and PA1.1 hardware which uses fsub.  The HP
>   > compiler doesn't have the problem since it multiplies by -1. instead.
> I think there was a case where that's not 100% valid either, though I think
> it would be closer to conforming behavior than fsub.
> 
> FWIW, it may be the case that PA1.0 had fneg -- I don't have my manuals
> handy, but there were a few instructions in PA1.0 that got removed.

FWIW, FNEG is not in my 1989 manual, which I think is PA1.1.

> But I'm 100% certain fneg is available for PA2.0 and it does the right
> thing (I already checked it some time ago).
> 
> jeff

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: PATCH: HUGE_VAL should be Infinity

[Jeffrey A Law]

  In message <200011302016.PAA28575@hiauly1.hia.nrc.ca>you write:
  > The fneg instruction on PA2.0 gear does negate +0. correctly.  Thus, there
  > is only a problem with PA1.0 and PA1.1 hardware which uses fsub.  The HP
  > compiler doesn't have the problem since it multiplies by -1. instead.
I think there was a case where that's not 100% valid either, though I think
it would be closer to conforming behavior than fsub.

FWIW, it may be the case that PA1.0 had fneg -- I don't have my manuals
handy, but there were a few instructions in PA1.0 that got removed.

But I'm 100% certain fneg is available for PA2.0 and it does the right
thing (I already checked it some time ago).

jeff

Re: PATCH: HUGE_VAL should be Infinity

[John David Anglin]

> > 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 retested this and it appears that I made a mistake in my original testing.
The fneg instruction on PA2.0 gear does negate +0. correctly.  Thus, there
is only a problem with PA1.0 and PA1.1 hardware which uses fsub.  The HP
compiler doesn't have the problem since it multiplies by -1. instead.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)