On Sunday, June 29, 2003, at 08:37  AM, Krister Walfridsson wrote:

> I have no comments on fpgetprec() and fpsetprec(), but I don't think
> it is the correct way to remove the FP failures in the gcc testsuite...
>
> It is IMHO much better to make gcc understand that NetBSD defaults to
> double-precision (which is what I believe RTH's old
> ieee_extended_intel_96_round_53_format patch to gcc/real.[ch] does.
> See Loren's updated patch, sent to gcc-patches last week...)

Unfortunately, applying the change to use intel_96_round_53 on 
i386-netbsd* seems to have caused regressions.  This puzzles me 
somewhat.

  FAIL: gcc.c-torture/execute/ieee/rbug.c execution,  -O0
  FAIL: gcc.c-torture/execute/ieee/rbug.c execution,  -O1
  FAIL: gcc.c-torture/execute/ieee/rbug.c execution,  -O2
+FAIL: gcc.c-torture/execute/ieee/rbug.c execution,  -O3 
-fomit-frame-pointer
+FAIL: gcc.c-torture/execute/ieee/rbug.c execution,  -O3 -g
  FAIL: gcc.c-torture/execute/ieee/rbug.c execution,  -Os
  XPASS: gcc.dg/cpp/cmdlne-dI-M.c scan-file 
(^|\\n)cmdlne-dI-M.*:[^\\n]*cmdlne-dI-M.c
  XPASS: gcc.dg/cpp/cmdlne-dM-M.c scan-file 
(^|\\n)cmdlne-dM-M[^\\n]*:[^\\n]*cmdlne-dM-M.c
  FAIL: gcc.dg/20030626-1.c  (test for bogus messages, line 17)
  FAIL: gcc.dg/builtins-20.c (test for excess errors)
  FAIL: gcc.dg/const-elim-1.c scan-assembler-not LC[^A-Z]
+FAIL: gcc.dg/i386-387-3.c scan-assembler fldpi
+FAIL: gcc.dg/i386-387-4.c scan-assembler fldpi
  FAIL: gcc.dg/warn-1.c  (test for warnings, line 15)
  FAIL: gcc.dg/pch/common-1.c  -O3 -fomit-frame-pointer  assembly 
comparison
  FAIL: gcc.dg/pch/common-1.c  -O3 -g  assembly comparison
@@ -66,8 +70,8 @@

                 === gcc Summary ===

-# of expected passes           22804
-# of unexpected failures       16
+# of expected passes           22800
+# of unexpected failures       20
  # of unexpected successes      2
  # of expected failures         73
  # of unsupported tests         134

I guess there are two interesting things here:

	1. ieee/rbug.c succeeds without the patch at -O3.  I don't
	   recall this being the case before.  I need to go look
	   back through older results.

	2. If it succeeds at -O3, why does it fail at < -O3?

	3. The patch causes the i387 pi constant to not be recognized
	   properly.  Why didn't this happen for FreeBSD, too?

         -- Jason R. Thorpe <thorpej@wasabisystems.com>