* Compiler problem in glibc
@ 2002-03-17 10:52 Hartvig Ekner
2002-03-17 10:52 ` Hartvig Ekner
2002-03-17 18:41 ` H . J . Lu
0 siblings, 2 replies; 4+ messages in thread
From: Hartvig Ekner @ 2002-03-17 10:52 UTC (permalink / raw)
To: user alias
I have found a problem in glibc caused by the gcc-2.96-99.1 compiler
from H.J's miniport.
in the exp() function (file w_expf.c), there is code like:
#ifdef __STDC__
float __expf(float x) /* wrapper expf */
#else
float __expf(x) /* wrapper expf */
float x;
#endif
{
#ifdef _IEEE_LIBM
return __ieee754_expf(x);
#else
float z;
z = __ieee754_expf(x);
if(_LIB_VERSION == _IEEE_) return z;
if(__finitef(x)) {
if(x>o_threshold)
(IEEE_LIBM is not set). Note that there are two function calls (ieee754_expf
and finitef()) followed by a FP if-statement (x>o_threshold). This
translates into:
00400570 <__expf>:
400570: 3c1c0fc1 lui gp,0xfc1
400574: 279cc090 addiu gp,gp,-16240
400578: 0399e021 addu gp,gp,t9
40057c: 27bdffc8 addiu sp,sp,-56
400580: afbc0018 sw gp,24(sp)
400584: e7b60030 swc1 $f22,48(sp)
400588: e7b70034 swc1 $f23,52(sp)
40058c: e7b40028 swc1 $f20,40(sp)
400590: e7b5002c swc1 $f21,44(sp)
400594: afbf0024 sw ra,36(sp)
400598: 46006506 mov.s $f20,$f12
40059c: afbc0020 sw gp,32(sp)
4005a0: 8f998630 lw t9,-31184(gp)
4005a4: 00000000 nop
4005a8: 0320f809 jalr t9 __ieee754_expf
4005ac: 00000000 nop
4005b0: 8fbc0018 lw gp,24(sp)
4005b4: 00000000 nop
4005b8: 8f8388f4 lw v1,-30476(gp)
4005bc: 00000000 nop
4005c0: 8c630000 lw v1,0(v1)
4005c4: 2402ffff li v0,-1
4005c8: 46000586 mov.s $f22,$f0
4005cc: 1062002d beq v1,v0,400684 <__expf+0x114>
4005d0: 4600a306 mov.s $f12,$f20
4005d4: 8f9986d0 lw t9,-31024(gp)
4005d8: 00000000 nop
4005dc: 0320f809 jalr t9 finitef()
4005e0: 00000000 nop
4005e4: 8fbc0018 lw gp,24(sp)
4005e8: 00000000 nop
4005ec: 3c0142b1 lui at,0x42b1
4005f0: 34217180 ori at,at,0x7180
4005f4: 44810000 mtc1 at,$f0
4005f8: 00000000 nop
4005fc: 4614003c c.lt.s $f0,$f20 Wow!!!!
...
400608: 1040001e beqz v0,400684 <__expf+0x114>
40060c: 4600b006 mov.s $f0,$f22
400610: 4500000b bc1f 400640 <__expf+0xd0>
Note that the c.lt.s (from the FP compare) is done before the finitef()
value has been checked (beqz in 400608). This particular issue causes
the wrong setting of bits in the FPU SR in some cases (with exp(nan)),
and "make check" in glibc to fail.
BTW, the "make check" in glibc has so far turned up a few other items in
glibc as well as in the kernel (FPU emulator), which are being fixed.
/Hartvig
--
_ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com
|\ /| | |____)(____ Direct: +45 4486 5503
| \/ | | | _____) MIPS Denmark Switch: +45 4486 5555
T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556
^ permalink raw reply [flat|nested] 4+ messages in thread
* Compiler problem in glibc
2002-03-17 10:52 Compiler problem in glibc Hartvig Ekner
@ 2002-03-17 10:52 ` Hartvig Ekner
2002-03-17 18:41 ` H . J . Lu
1 sibling, 0 replies; 4+ messages in thread
From: Hartvig Ekner @ 2002-03-17 10:52 UTC (permalink / raw)
To: user alias
I have found a problem in glibc caused by the gcc-2.96-99.1 compiler
from H.J's miniport.
in the exp() function (file w_expf.c), there is code like:
#ifdef __STDC__
float __expf(float x) /* wrapper expf */
#else
float __expf(x) /* wrapper expf */
float x;
#endif
{
#ifdef _IEEE_LIBM
return __ieee754_expf(x);
#else
float z;
z = __ieee754_expf(x);
if(_LIB_VERSION == _IEEE_) return z;
if(__finitef(x)) {
if(x>o_threshold)
(IEEE_LIBM is not set). Note that there are two function calls (ieee754_expf
and finitef()) followed by a FP if-statement (x>o_threshold). This
translates into:
00400570 <__expf>:
400570: 3c1c0fc1 lui gp,0xfc1
400574: 279cc090 addiu gp,gp,-16240
400578: 0399e021 addu gp,gp,t9
40057c: 27bdffc8 addiu sp,sp,-56
400580: afbc0018 sw gp,24(sp)
400584: e7b60030 swc1 $f22,48(sp)
400588: e7b70034 swc1 $f23,52(sp)
40058c: e7b40028 swc1 $f20,40(sp)
400590: e7b5002c swc1 $f21,44(sp)
400594: afbf0024 sw ra,36(sp)
400598: 46006506 mov.s $f20,$f12
40059c: afbc0020 sw gp,32(sp)
4005a0: 8f998630 lw t9,-31184(gp)
4005a4: 00000000 nop
4005a8: 0320f809 jalr t9 __ieee754_expf
4005ac: 00000000 nop
4005b0: 8fbc0018 lw gp,24(sp)
4005b4: 00000000 nop
4005b8: 8f8388f4 lw v1,-30476(gp)
4005bc: 00000000 nop
4005c0: 8c630000 lw v1,0(v1)
4005c4: 2402ffff li v0,-1
4005c8: 46000586 mov.s $f22,$f0
4005cc: 1062002d beq v1,v0,400684 <__expf+0x114>
4005d0: 4600a306 mov.s $f12,$f20
4005d4: 8f9986d0 lw t9,-31024(gp)
4005d8: 00000000 nop
4005dc: 0320f809 jalr t9 finitef()
4005e0: 00000000 nop
4005e4: 8fbc0018 lw gp,24(sp)
4005e8: 00000000 nop
4005ec: 3c0142b1 lui at,0x42b1
4005f0: 34217180 ori at,at,0x7180
4005f4: 44810000 mtc1 at,$f0
4005f8: 00000000 nop
4005fc: 4614003c c.lt.s $f0,$f20 Wow!!!!
...
400608: 1040001e beqz v0,400684 <__expf+0x114>
40060c: 4600b006 mov.s $f0,$f22
400610: 4500000b bc1f 400640 <__expf+0xd0>
Note that the c.lt.s (from the FP compare) is done before the finitef()
value has been checked (beqz in 400608). This particular issue causes
the wrong setting of bits in the FPU SR in some cases (with exp(nan)),
and "make check" in glibc to fail.
BTW, the "make check" in glibc has so far turned up a few other items in
glibc as well as in the kernel (FPU emulator), which are being fixed.
/Hartvig
--
_ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com
|\ /| | |____)(____ Direct: +45 4486 5503
| \/ | | | _____) MIPS Denmark Switch: +45 4486 5555
T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Compiler problem in glibc
2002-03-17 10:52 Compiler problem in glibc Hartvig Ekner
2002-03-17 10:52 ` Hartvig Ekner
@ 2002-03-17 18:41 ` H . J . Lu
1 sibling, 0 replies; 4+ messages in thread
From: H . J . Lu @ 2002-03-17 18:41 UTC (permalink / raw)
To: Hartvig Ekner; +Cc: user alias
On Sun, Mar 17, 2002 at 11:52:15AM +0100, Hartvig Ekner wrote:
> I have found a problem in glibc caused by the gcc-2.96-99.1 compiler
> from H.J's miniport.
>
> in the exp() function (file w_expf.c), there is code like:
>
> #ifdef __STDC__
> float __expf(float x) /* wrapper expf */
> #else
> float __expf(x) /* wrapper expf */
> float x;
> #endif
> {
> #ifdef _IEEE_LIBM
> return __ieee754_expf(x);
> #else
> float z;
> z = __ieee754_expf(x);
> if(_LIB_VERSION == _IEEE_) return z;
>
> if(__finitef(x)) {
> if(x>o_threshold)
>
>
> (IEEE_LIBM is not set). Note that there are two function calls (ieee754_expf
> and finitef()) followed by a FP if-statement (x>o_threshold). This
> translates into:
>
I believe it has been reported before and is fixed in gcc 3.1 at the
time.
H.J.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Compiler problem in glibc
@ 2002-03-18 0:55 Zhang Fuxin
0 siblings, 0 replies; 4+ messages in thread
From: Zhang Fuxin @ 2002-03-18 0:55 UTC (permalink / raw)
To: Hartvig Ekner; +Cc: linux-mips@oss.sgi.com
hi,
good news to hear they are being fixed. I reported this problem
about one month ago,it was fixed in gcc3.1. But i have no time
to investigate other math test problems,wish you good luck:)
在 2002-03-17 11:52:00 you wrote：
>I have found a problem in glibc caused by the gcc-2.96-99.1 compiler
>from H.J's miniport.
>
>in the exp() function (file w_expf.c), there is code like:
>
>#ifdef __STDC__
> float __expf(float x) /* wrapper expf */
>#else
> float __expf(x) /* wrapper expf */
> float x;
>#endif
>{
>#ifdef _IEEE_LIBM
> return __ieee754_expf(x);
>#else
> float z;
> z = __ieee754_expf(x);
> if(_LIB_VERSION == _IEEE_) return z;
>
> if(__finitef(x)) {
> if(x>o_threshold)
>
>
>(IEEE_LIBM is not set). Note that there are two function calls (ieee754_expf
>and finitef()) followed by a FP if-statement (x>o_threshold). This
>translates into:
>
>00400570 <__expf>:
> 400570: 3c1c0fc1 lui gp,0xfc1
> 400574: 279cc090 addiu gp,gp,-16240
> 400578: 0399e021 addu gp,gp,t9
> 40057c: 27bdffc8 addiu sp,sp,-56
> 400580: afbc0018 sw gp,24(sp)
> 400584: e7b60030 swc1 $f22,48(sp)
> 400588: e7b70034 swc1 $f23,52(sp)
> 40058c: e7b40028 swc1 $f20,40(sp)
> 400590: e7b5002c swc1 $f21,44(sp)
> 400594: afbf0024 sw ra,36(sp)
> 400598: 46006506 mov.s $f20,$f12
> 40059c: afbc0020 sw gp,32(sp)
> 4005a0: 8f998630 lw t9,-31184(gp)
> 4005a4: 00000000 nop
> 4005a8: 0320f809 jalr t9 __ieee754_expf
> 4005ac: 00000000 nop
> 4005b0: 8fbc0018 lw gp,24(sp)
> 4005b4: 00000000 nop
> 4005b8: 8f8388f4 lw v1,-30476(gp)
> 4005bc: 00000000 nop
> 4005c0: 8c630000 lw v1,0(v1)
> 4005c4: 2402ffff li v0,-1
> 4005c8: 46000586 mov.s $f22,$f0
> 4005cc: 1062002d beq v1,v0,400684 <__expf+0x114>
> 4005d0: 4600a306 mov.s $f12,$f20
> 4005d4: 8f9986d0 lw t9,-31024(gp)
> 4005d8: 00000000 nop
> 4005dc: 0320f809 jalr t9 finitef()
> 4005e0: 00000000 nop
> 4005e4: 8fbc0018 lw gp,24(sp)
> 4005e8: 00000000 nop
> 4005ec: 3c0142b1 lui at,0x42b1
> 4005f0: 34217180 ori at,at,0x7180
> 4005f4: 44810000 mtc1 at,$f0
> 4005f8: 00000000 nop
> 4005fc: 4614003c c.lt.s $f0,$f20 Wow!!!!
> ...
> 400608: 1040001e beqz v0,400684 <__expf+0x114>
> 40060c: 4600b006 mov.s $f0,$f22
> 400610: 4500000b bc1f 400640 <__expf+0xd0>
>
>
>Note that the c.lt.s (from the FP compare) is done before the finitef()
>value has been checked (beqz in 400608). This particular issue causes
>the wrong setting of bits in the FPU SR in some cases (with exp(nan)),
>and "make check" in glibc to fail.
>
>BTW, the "make check" in glibc has so far turned up a few other items in
>glibc as well as in the kernel (FPU emulator), which are being fixed.
>
>/Hartvig
>
>--
> _ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com
> |\ /| | |____)(____ Direct: +45 4486 5503
> | \/ | | | _____) MIPS Denmark Switch: +45 4486 5555
>T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556
Regards
Zhang Fuxin
fxzhang@ict.ac.cn
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-03-18 0:53 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-03-17 10:52 Compiler problem in glibc Hartvig Ekner
2002-03-17 10:52 ` Hartvig Ekner
2002-03-17 18:41 ` H . J . Lu
-- strict thread matches above, loose matches on Subject: below --
2002-03-18 0:55 Zhang Fuxin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox