Looking at the fcr31 bug I found some other bug which probably isn't causing
what you observe but is a bug anyway - fpu_control_t was a 16-bit type
but should be a 32-bit type. Patch below.
Is _FPU_IEEE used at all and is it's definition right?
I asked more people to run your test program. The result is that glibc
2.0.6 (both shared and static tried) and 2.2 print ``0 0'' while glibc
2.0.7 prints a non-zero value.
Can you check if the variable __fpu_control, is it's value non-zero?
2000-07-05 Ralf Baechle <firstname.lastname@example.org>
* sysdeps/mips/fpu_control.h: Make fpu_control_t a 32-bit type.
--- libc/sysdeps/mips/fpu_control.h.orig Wed Jul 5 02:51:54 2000
+++ libc/sysdeps/mips/fpu_control.h Wed Jul 5 02:52:58 2000
@@ -1,5 +1,5 @@
/* FPU control word bits. Mips version.
- Copyright (C) 1996, 1997, 1998, 1999 Free Software Foundation, Inc.
+ Copyright (C) 1996, 1997, 1998, 1999, 2000 Free Software Foundation, Inc.
This file is part of the GNU C Library.
Contributed by Olaf Flebbe and Ralf Baechle.
@@ -86,10 +86,10 @@
#define _FPU_IEEE 0x00000F80
/* Type of the control word. */
-typedef unsigned int fpu_control_t __attribute__ ((__mode__ (__HI__)));
+typedef unsigned int fpu_control_t __attribute__ ((__mode__ (__SI__)));
/* Macros for accessing the hardware control word. */
-#define _FPU_GETCW(cw) __asm__ ("cfc1 %0,$31" : "=r" (cw) : )
+#define _FPU_GETCW(cw) __asm__ ("cfc1 %0,$31" : "=r" (cw))
#define _FPU_SETCW(cw) __asm__ ("ctc1 %0,$31" : : "r" (cw))
/* Default control word set at startup. */