TLS toolchain update (6 regressions left)
Please stand up and pat yourself on the back:
make[2]: *** [/glibc/math/test-fenv.out] Error 1
= Regression (1)
make[2]: *** [/glibc/math/test-float.out] Error 1 make[2]: *** [/glibc/math/test-double.out] Error 1 make[2]: *** [/glibc/math/test-ifloat.out] Error 1 make[2]: *** [/glibc/math/test-idouble.out] Error 1 make[1]: *** [math/tests] Error 2
make[2]: *** [/glibc/stdlib/tst-strtod.out] Error 1 make[2]: *** [/glibc/stdlib/bug-strtod.out] Error 1 make[1]: *** [stdlib/tests] Error 2
make[2]: [/glibc/posix/annexc.out] Error 1 (ignored) make[2]: *** [/glibc/elf/tst-array1.out] Error 1 make[2]: *** [/glibc/elf/tst-array2.out] Error 1 make[2]: *** [/glibc/elf/tst-array3.out] Error 1 make[2]: *** [/glibc/elf/tst-array4.out] Error 1 make[2]: *** [/glibc/elf/tst-array1-static.out] Error 1
= Regressions (5)
make[2]: *** [/glibc/elf/tst-tls13.out] Error 1
= TIMEOUTFACTOR=10 required.
make[1]: *** [elf/tests] Error 2
make: *** [check] Error 2
That's 6 regressions for the C Library, which I'll target over the next couple of weeks.
The last big error was that glibc was considering the build a cross-compile and the environment just puked.
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
[parisc-linux] Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 13 lines · Carlos O'Donell
make[2]: *** [/glibc/math/test-fenv.out] Error 1
= Regression (1)
make[2]: *** [/glibc/math/test-float.out] Error 1 make[2]: *** [/glibc/math/test-double.out] Error 1 make[2]: *** [/glibc/math/test-ifloat.out] Error 1 make[2]: *** [/glibc/math/test-idouble.out] Error 1 make[1]: *** [math/tests] Error 2
make[2]: *** [/glibc/stdlib/tst-strtod.out] Error 1 make[2]: *** [/glibc/stdlib/bug-strtod.out] Error 1 make[1]: *** [stdlib/tests] Error 2
make[2]: [/glibc/posix/annexc.out] Error 1 (ignored) make[2]: *** [/glibc/elf/tst-array1.out] Error 1 make[2]: *** [/glibc/elf/tst-array2.out] Error 1
Quoted 8 lines
make[2]: *** [/glibc/elf/tst-array3.out] Error 1 make[2]: *** [/glibc/elf/tst-array4.out] Error 1 make[2]: *** [/glibc/elf/tst-array1-static.out] Error 1
= Regressions (5)
make[2]: *** [/glibc/elf/tst-tls13.out] Error 1
= TIMEOUTFACTOR=10 required.
make[1]: *** [elf/tests] Error 2
make: *** [check] Error 2
Fixed binutils...
Make that 1 regression:
make[2]: *** [/glibc/math/test-fenv.out] Error 1 make[2]: *** [/glibc/math/test-float.out] Error 1 make[2]: *** [/glibc/math/test-double.out] Error 1 make[2]: *** [/glibc/math/test-ifloat.out] Error 1 make[2]: *** [/glibc/math/test-idouble.out] Error 1 make[1]: *** [math/tests] Error 2
make[2]: *** [/glibc/stdlib/tst-strtod.out] Error 1 make[2]: *** [/glibc/stdlib/bug-strtod.out] Error 1 make[1]: *** [stdlib/tests] Error 2
make[2]: [/glibc/posix/annexc.out] Error 1 (ignored)
make: *** [check] Error 2
However, the following is troubling and where trouble goes, so does the blame on the compiler.
test-float.out (Non-inline float):
Test suite completed:
2599 test cases plus 2384 tests for exception flags executed.
- 39 errors occurred.
+ 4363 errors occurred.
test-double.out (Non-inline double):
Test suite completed:
2624 test cases plus 2399 tests for exception flags executed.
- 38 errors occurred.
+ 4388 errors occurred.
Although the numbers don't add up with the errors a cursory check shows *none* of the non-inline math tests passed.
The inline math does *much* better, observe:
test-ifloat.out (Inline float):
Test suite completed:
2537 test cases plus 2322 tests for exception flags executed.
- 1 errors occurred.
+ 11 errors occurred.
test-idbouble.out (Inline double):
Test suite completed:
2562 test cases plus 2337 tests for exception flags executed.
- 1 errors occurred.
+ 10 errors occurred.
c.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
[parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 15 lines
However, the following is troubling and where trouble goes, so does the blame on the compiler.
test-float.out (Non-inline float):
Test suite completed:
2599 test cases plus 2384 tests for exception flags executed.(quoted diff) +1
-1- 39 errors occurred. + 4363 errors occurred.test-double.out (Non-inline double):
Test suite completed:
2624 test cases plus 2399 tests for exception flags executed.(quoted diff) +1
-1- 38 errors occurred. + 4388 errors occurred.
Quoted 2 lines
Although the numbers don't add up with the errors a cursory check shows *none* of the non-inline math tests passed.
I don't want to throw stones but I posted a message to parisc two days ago indicating that we have at least one kernel bug in its math emulation ;)
Ok, PA 2.0 support could be suspect. I doubt very much there are major FP issues with PA 1.1. In PA 1.1, essentially all the operations are supported in hardware (I hate assist). There's an issue with complex support using PA 1.0 but if the compiler didn't die that's not likely the problem. That's fixed in main. Finally, you've got the glibc issue in handling 64-bit long doubles. I would suspect a glibc issue first. GCC doesn't have much to do with exception support or control of rounding modes, although you would think the compiler would need to know about rounding mode.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
[parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 15 lines · John David Anglin
Quoted 15 lines
However, the following is troubling and where trouble goes, so does the blame on the compiler.
test-float.out (Non-inline float):
Test suite completed:
2599 test cases plus 2384 tests for exception flags executed.(quoted diff) +1
-1- 39 errors occurred. + 4363 errors occurred.test-double.out (Non-inline double):
Test suite completed:
2624 test cases plus 2399 tests for exception flags executed.(quoted diff) +1
-1- 38 errors occurred. + 4388 errors occurred.
Quoted 6 lines
Quoted 2 lines
Although the numbers don't add up with the errors a cursory check shows *none* of the non-inline math tests passed.
I don't want to throw stones but I posted a message to parisc two days ago indicating that we have at least one kernel bug in its math emulation ;)
I knew I'd draw you ire if I blamed the compiler! :)
Quoted 9 lines
Ok, PA 2.0 support could be suspect. I doubt very much there are major FP issues with PA 1.1. In PA 1.1, essentially all the operations are supported in hardware (I hate assist). There's an issue with complex support using PA 1.0 but if the compiler didn't die that's not likely the problem. That's fixed in main. Finally, you've got the glibc issue in handling 64-bit long doubles. I would suspect a glibc issue first. GCC doesn't have much to do with exception support or control of rounding modes, although you would think the compiler would need to know about rounding mode.
I'm only testing float and double support, I have temporarily disabled long double support for hppa during testing.
I don't quite understand how something like "fpclassify" can *ever* fail under any implementation.
Could you review these files:
http://cvs.parisc-linux.org/glibc/sysdeps/hppa/fpu/
With an eye to correct asm statement? If these don't work then it all goes down the tubes. I'm sure gcc is probably doing the right thing and that asm is doing the wrong thing.
c.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 9 lines · Carlos O'Donell
I don't quite understand how something like "fpclassify" can *ever* fail under any implementation.
Could you review these files:
http://cvs.parisc-linux.org/glibc/sysdeps/hppa/fpu/With an eye to correct asm statement? If these don't work then it all goes down the tubes. I'm sure gcc is probably doing the right thing and that asm is doing the wrong thing.
I think gcc is to blame, or the constraints in the assembly?
--- GCC 4.0 ---
0x40349890 <feclearexcept+0>: ldo 40(sp),sp 0x40349894 <feclearexcept+4>: ldo -38(sp),ret0 0x40349898 <feclearexcept+8>: stw r19,-20(,sp) 0x4034989c <feclearexcept+12>: fstd fr0,0(,ret0) 0x403498a0 <feclearexcept+16>: fldd 0(,ret0),fr0 0x403498a4 <feclearexcept+20>: ldi 0,ret0 0x403498a8 <feclearexcept+24>: bv r0(rp) 0x403498ac <feclearexcept+28>: ldo -40(sp),sp
Notice that it thinks the argument is on the stack? Are the assembly constraints confusing gcc?
The above is competely bogus.
--- GCC 3.3.5 ---
00000000 <feclearexcept>:
0: 37 de 00 80 ldo 40(sp),sp 4: d7 5a 0b 7b depw,z r26,4,5,r26 8: 6b d3 3f c1 stw r19,-20(,sp) c: 37 d4 3f 91 ldo -38(sp),r20 10: 2e 80 12 00 fstd fr0,0(,r20) 14: 4b d5 3f 91 ldw -38(,sp),r21 18: 0b 55 00 1a andcm r21,r26,r26 1c: 6b da 3f 91 stw r26,-38(,sp) 20: 2e 80 10 00 fldd 0(,r20),fr0 24: 34 1c 00 00 ldi 0,ret0 28: e8 40 c0 00 bv r0(rp) 2c: 37 de 3f 81 ldo -40(sp),sp
This one properly loads the value from r26. This one works.
c.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 4 lines
I think gcc is to blame, or the constraints in the assembly?
--- GCC 4.0 ---
Quoted 8 lines
0x40349890 <feclearexcept+0>: ldo 40(sp),sp 0x40349894 <feclearexcept+4>: ldo -38(sp),ret0 0x40349898 <feclearexcept+8>: stw r19,-20(,sp) 0x4034989c <feclearexcept+12>: fstd fr0,0(,ret0) 0x403498a0 <feclearexcept+16>: fldd 0(,ret0),fr0 0x403498a4 <feclearexcept+20>: ldi 0,ret0 0x403498a8 <feclearexcept+24>: bv r0(rp) 0x403498ac <feclearexcept+28>: ldo -40(sp),sp
PR time. Please add [email protected] to the CC list.
Quoted 2 lines
Notice that it thinks the argument is on the stack? Are the assembly constraints confusing gcc?
Probably, but its not clear at the moment. I think the asm's need the volatile keyword as they have side effects that aren't known to gcc (i.e., scheduling might move a floating point operation past the asm's should the functions be inlined.
Taking a quick look, I see the and has been removed from the initial rtl generation. So, this is a tree optimization bug.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 15 lines · John David Anglin
Quoted 4 lines
I think gcc is to blame, or the constraints in the assembly?
--- GCC 4.0 ---
Quoted 8 lines
0x40349890 <feclearexcept+0>: ldo 40(sp),sp 0x40349894 <feclearexcept+4>: ldo -38(sp),ret0 0x40349898 <feclearexcept+8>: stw r19,-20(,sp) 0x4034989c <feclearexcept+12>: fstd fr0,0(,ret0) 0x403498a0 <feclearexcept+16>: fldd 0(,ret0),fr0 0x403498a4 <feclearexcept+20>: ldi 0,ret0 0x403498a8 <feclearexcept+24>: bv r0(rp) 0x403498ac <feclearexcept+28>: ldo -40(sp),spPR time. Please add [email protected] to the CC list.
Quoted 7 lines
Quoted 2 lines
Notice that it thinks the argument is on the stack? Are the assembly constraints confusing gcc?
Probably, but its not clear at the moment. I think the asm's need the volatile keyword as they have side effects that aren't known to gcc (i.e., scheduling might move a floating point operation past the asm's should the functions be inlined.
I hadn't considered the effects of rescheduling. I guess this can happen to any code between the asm statements.
c.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 2 lines
I hadn't considered the effects of rescheduling. I guess this can happen to any code between the asm statements.
As long as the dependencies are correct, then then shouldn't happen. Possibly, adding a dependency on register "CCFP" is what's needed. I don't know if that actually works but it's how we handle floating-point condition codes internally. I think that would allow inlining of these routines in code that does floating-point compares and tests.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 8 lines · John David Anglin
Quoted 2 lines
I hadn't considered the effects of rescheduling. I guess this can happen to any code between the asm statements.
As long as the dependencies are correct, then then shouldn't happen. Possibly, adding a dependency on register "CCFP" is what's needed. I don't know if that actually works but it's how we handle floating-point condition codes internally. I think that would allow inlining of these routines in code that does floating-point compares and tests.
What sort of dependancy on CCFP? Do you have an example somewhere?
c.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 1 line
What sort of dependancy on CCFP? Do you have an example somewhere?
No.
If your assembler instruction can alter the condition code register, add @samp{cc} to the list of clobbered registers. GCC on some machines represents the condition codes as a specific hardware register; @samp{cc} serves to name this register. On other machines, the condition code is handled differently, and specifying @samp{cc} has no effect. But it is valid no matter what the machine.
Thinking a little more, I believe specifying "r0" in the clobber list of the asm will do the job. Register 0 is used to hold condition codes for both integer and floating point comparisons. I don't think there's a way to express that the register is only used. There's no constraint letter for r0, etc.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 11 lines · John David Anglin
Quoted 1 line
What sort of dependancy on CCFP? Do you have an example somewhere?
No.
If your assembler instruction can alter the condition code register, add @samp{cc} to the list of clobbered registers. GCC on some machines represents the condition codes as a specific hardware register; @samp{cc} serves to name this register. On other machines, the condition code is handled differently, and specifying @samp{cc} has no effect. But it is valid no matter what the machine.
Quoted 5 lines
Thinking a little more, I believe specifying "r0" in the clobber list of the asm will do the job. Register 0 is used to hold condition codes for both integer and floating point comparisons. I don't think there's a way to express that the register is only used. There's no constraint letter for r0, etc.
Will this ever happen during inlining?
fstd chain -> memory
operation 1
fstd chain -> memory fldd chain -> regs operation 2 fldd chain -> regs
Operation 2 could trap when expected that it couldn't because the fstd had cleared the traps.
c.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 11 lines
Will this ever happen during inlining?
fstd chain -> memory
operation 1fstd chain -> memory fldd chain -> regs operation 2 fldd chain -> regsOperation 2 could trap when expected that it couldn't because the fstd had cleared the traps.
I guess clobbering all the fp registers plus r0 will stop this.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 9 lines · John David Anglin
Quoted 9 lines
Will this ever happen during inlining?
fstd chain -> memory
operation 1fstd chain -> memory fldd chain -> regs operation 2 fldd chain -> regs
Quoted 4 lines
Quoted 2 lines
Operation 2 could trap when expected that it couldn't because the fstd had cleared the traps.
I guess clobbering all the fp registers plus r0 will stop this.
That seems like overkill, I just don't want gcc schedule between the asm statements. The fstd chain, and fldd chain are always asm statements.
Is there no other way? Clobbering will add huge register pressure and force gcc to spill all the fpregs and restore after the call.
c.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).
Quoted 7 lines
Quoted 1 line
I guess clobbering all the fp registers plus r0 will stop this.
That seems like overkill, I just don't want gcc schedule between the asm statements. The fstd chain, and fldd chain are always asm statements.
Is there no other way? Clobbering will add huge register pressure and force gcc to spill all the fpregs and restore after the call.
Hmmm, this seems tricky:
For example, on many targets there is a system register which can be set to control the rounding mode of floating point operations. You might try
setting it with a volatile @code{asm}, like this PowerPC example:
@smallexample
asm volatile("mtfsf 255,%0" : : "f" (fpenv));
sum = x + y;@end smallexample
@noindent
This will not work reliably, as the compiler may move the addition back before the volatile @code{asm}. To make it work you need to add an artificial dependency to the @code{asm} referencing a variable in the code you don't want moved, for example:
@smallexample
asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
sum = x + y;@end smallexample
...
For reasons similar to those described above, it is not possible to give an assembler instruction access to the condition code left by previous instructions.
If you clobber memory in the asm, then I think it will be a barrier for memory accesses. I think a function call is ok:
a = b + c; z = xyzzy ();
I don't think gcc can reorder the two operations unless it can prove the function is pure and doesn't write all memory.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 15 lines · Carlos O'Donell
Please stand up and pat yourself on the back:
make[2]: *** [/glibc/math/test-fenv.out] Error 1
= Regression (1)
make[2]: *** [/glibc/math/test-float.out] Error 1 make[2]: *** [/glibc/math/test-double.out] Error 1 make[2]: *** [/glibc/math/test-ifloat.out] Error 1 make[2]: *** [/glibc/math/test-idouble.out] Error 1 make[1]: *** [math/tests] Error 2
make[2]: *** [/glibc/stdlib/tst-strtod.out] Error 1 make[2]: *** [/glibc/stdlib/bug-strtod.out] Error 1 make[1]: *** [stdlib/tests] Error 2
make[2]: [/glibc/posix/annexc.out] Error 1 (ignored) make[2]: *** [/glibc/elf/tst-array1.out] Error 1 make[2]: *** [/glibc/elf/tst-array2.out] Error 1
Quoted 8 lines
make[2]: *** [/glibc/elf/tst-array3.out] Error 1 make[2]: *** [/glibc/elf/tst-array4.out] Error 1 make[2]: *** [/glibc/elf/tst-array1-static.out] Error 1
= Regressions (5)
make[2]: *** [/glibc/elf/tst-tls13.out] Error 1
= TIMEOUTFACTOR=10 required.
make[1]: *** [elf/tests] Error 2
make: *** [check] Error 2
Patched up the floating point asm constraints.
make[2]: *** [/glibc/math/test-float.out] Error 1 make[2]: *** [/glibc/math/test-double.out] Error 1 make[2]: *** [/glibc/math/test-ifloat.out] Error 1 make[2]: *** [/glibc/math/test-idouble.out] Error 1 make[1]: *** [math/tests] Error 2
make[2]: *** [/glibc/stdlib/tst-strtod.out] Error 1 make[2]: *** [/glibc/stdlib/bug-strtod.out] Error 1 make[1]: *** [stdlib/tests] Error 2
make[2]: [/glibc/posix/annexc.out] Error 1 (ignored)
make: *** [check] Error 2
No regressions. But we still have a couple of functions that look like the math is a bit wrong. However, we are doing better than non-tls, I figure because the constraints are still a bit wrong.
----- GCC 4.0 (glibc + fp constriant fix + tls) ----- ==> test-double.out <==
Test suite completed:
2624 test cases plus 2399 tests for exception flags executed. 24 errors occurred.
==> test-float.out <==
Test suite completed:
2599 test cases plus 2384 tests for exception flags executed. 23 errors occurred.
==> test-idouble.out <==
Test suite completed:
2562 test cases plus 2337 tests for exception flags executed. 10 errors occurred.
==> test-ifloat.out <==
Test suite completed:
2537 test cases plus 2322 tests for exception flags executed. 11 errors occurred.
----- GCC 3.3.5 (glibc) -----
==> test-double.out <==
Test suite completed:
2624 test cases plus 2399 tests for exception flags executed. 38 errors occurred.
==> test-float.out <==
Test suite completed:
2599 test cases plus 2384 tests for exception flags executed. 39 errors occurred.
==> test-idouble.out <==
Test suite completed:
2562 test cases plus 2337 tests for exception flags executed. 1 errors occurred.
==> test-ifloat.out <==
Test suite completed:
2537 test cases plus 2322 tests for exception flags executed. 1 errors occurred.
We are on par with the previous test results. I'm very pleased.
-----
Looking at the test failures in test-float, I see the following:
testing float (without inline functions)
Failure: Test: atan2 (-0.00756827042671106339, -.001792735857538728036) == -1.80338464113663849327153994379639112
Result:
is: -1.80338394641876220703e+00 -0x1.cdaa9200000000000000p+0 should be: -1.80338466167449951172e+00 -0x1.cdaa9e00000000000000p+0 difference: 7.15255737304687500000e-07 0x1.80000000000000000000p-21 ulp : 6.0000 max.ulp : 0.0000
I can't seem to fix this test, but I figure it's because I haven't played enough with ulps settings that flag the test as failed. The error is in the e-06 rang which really sucks. Any thoughts?
Next is a set of failures all related to "rint" for rounding an integer to the correct value. The failures are very werid.
Failure: Test: rint (1.5) == 1.0
Result:
is: 2.00000000000000000000e+00 0x1.00000000000000000000p+1 should be: 1.00000000000000000000e+00 0x1.00000000000000000000p+0 difference: 1.00000000000000000000e+00 0x1.00000000000000000000p+0 ulp : 8388608.0000 max.ulp : 0.0000
That ulp is bogus? Not to mention that the rounding direction is wrong.
Lastly is:
Failure: Real part of: cacos (inf + NaN i) == NaN + inf i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: cacos (-inf + NaN i) == NaN + inf i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN + inf i) == NaN - inf i: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN - inf i) == NaN + inf i: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN + NaN i) == NaN + NaN i: Exception "Invalid operation" set
Failure: Real part of: ccosh (inf + NaN i) == inf + NaN i: Exception "Invalid operation" set
Failure: Real part of: ccosh (-inf + NaN i) == inf + NaN i: Exception "Invalid operation" set
Failure: Real part of: cpow (NaN + NaN i, NaN + NaN i) == NaN + NaN i: Exception "Invalid operation" set
Failure: Real part of: csinh (0.0 + NaN i) == 0.0 + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (-0 + NaN i) == 0.0 + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (inf + NaN i) == inf + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Failure: Real part of: csinh (-inf + NaN i) == inf + NaN i plus sign of zero/inf not specified: Exception "Invalid operation" set
Which all looks like corner case tets for these functions and the processor is raising an exception. I've never had a chance or desire to look at these but I will when I have nothing better to do ;)
c.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux