* [parisc-linux] TLS toolchain update (6 regressions left) @ 2005-07-15 14:26 Carlos O'Donell 2005-07-15 23:44 ` [parisc-linux] Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression) Carlos O'Donell 2005-07-17 16:21 ` [parisc-linux] TLS toolchain update (6 regressions left) Carlos O'Donell 0 siblings, 2 replies; 15+ messages in thread From: Carlos O'Donell @ 2005-07-15 14:26 UTC (permalink / raw) To: John David Anglin, Randolph Chung, parisc-linux 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 parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* [parisc-linux] Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-15 14:26 [parisc-linux] TLS toolchain update (6 regressions left) Carlos O'Donell @ 2005-07-15 23:44 ` Carlos O'Donell 2005-07-16 0:08 ` [parisc-linux] " John David Anglin 2005-07-17 16:21 ` [parisc-linux] TLS toolchain update (6 regressions left) Carlos O'Donell 1 sibling, 1 reply; 15+ messages in thread From: Carlos O'Donell @ 2005-07-15 23:44 UTC (permalink / raw) To: John David Anglin, Randolph Chung, parisc-linux On Fri, Jul 15, 2005 at 10:26:10AM -0400, Carlos O'Donell wrote: > 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 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 parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-15 23:44 ` [parisc-linux] Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression) Carlos O'Donell @ 2005-07-16 0:08 ` John David Anglin 2005-07-16 0:57 ` Carlos O'Donell 0 siblings, 1 reply; 15+ messages in thread From: John David Anglin @ 2005-07-16 0:08 UTC (permalink / raw) To: Carlos O'Donell; +Cc: parisc-linux, tausq > 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. 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 -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-16 0:08 ` [parisc-linux] " John David Anglin @ 2005-07-16 0:57 ` Carlos O'Donell 2005-07-16 1:14 ` Carlos O'Donell 0 siblings, 1 reply; 15+ messages in thread From: Carlos O'Donell @ 2005-07-16 0:57 UTC (permalink / raw) To: John David Anglin; +Cc: parisc-linux, tausq On Fri, Jul 15, 2005 at 08:08:43PM -0400, John David Anglin wrote: > > 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. > > 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! :) > 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 parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-16 0:57 ` Carlos O'Donell @ 2005-07-16 1:14 ` Carlos O'Donell 2005-07-16 1:54 ` John David Anglin 0 siblings, 1 reply; 15+ messages in thread From: Carlos O'Donell @ 2005-07-16 1:14 UTC (permalink / raw) To: John David Anglin; +Cc: tausq, parisc-linux On Fri, Jul 15, 2005 at 08:57:15PM -0400, Carlos O'Donell wrote: > 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 parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-16 1:14 ` Carlos O'Donell @ 2005-07-16 1:54 ` John David Anglin 2005-07-16 18:38 ` Carlos O'Donell 0 siblings, 1 reply; 15+ messages in thread From: John David Anglin @ 2005-07-16 1:54 UTC (permalink / raw) To: Carlos O'Donell; +Cc: tausq, parisc-linux > 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 PR time. Please add danglin@gcc.gnu.org to the CC list. > 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 -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-16 1:54 ` John David Anglin @ 2005-07-16 18:38 ` Carlos O'Donell 2005-07-16 19:15 ` John David Anglin 0 siblings, 1 reply; 15+ messages in thread From: Carlos O'Donell @ 2005-07-16 18:38 UTC (permalink / raw) To: John David Anglin; +Cc: tausq, parisc-linux On Fri, Jul 15, 2005 at 09:54:25PM -0400, John David Anglin wrote: > > 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 > > PR time. Please add danglin@gcc.gnu.org to the CC list. > > > 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 parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-16 18:38 ` Carlos O'Donell @ 2005-07-16 19:15 ` John David Anglin 2005-07-16 19:16 ` Carlos O'Donell 0 siblings, 1 reply; 15+ messages in thread From: John David Anglin @ 2005-07-16 19:15 UTC (permalink / raw) To: Carlos O'Donell; +Cc: tausq, parisc-linux > 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 -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-16 19:15 ` John David Anglin @ 2005-07-16 19:16 ` Carlos O'Donell 2005-07-16 19:48 ` John David Anglin 0 siblings, 1 reply; 15+ messages in thread From: Carlos O'Donell @ 2005-07-16 19:16 UTC (permalink / raw) To: John David Anglin; +Cc: tausq, parisc-linux On Sat, Jul 16, 2005 at 03:15:34PM -0400, John David Anglin wrote: > > 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 parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-16 19:16 ` Carlos O'Donell @ 2005-07-16 19:48 ` John David Anglin 2005-07-16 20:13 ` Carlos O'Donell 0 siblings, 1 reply; 15+ messages in thread From: John David Anglin @ 2005-07-16 19:48 UTC (permalink / raw) To: Carlos O'Donell; +Cc: tausq, parisc-linux > 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 -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-16 19:48 ` John David Anglin @ 2005-07-16 20:13 ` Carlos O'Donell 2005-07-16 20:29 ` John David Anglin 0 siblings, 1 reply; 15+ messages in thread From: Carlos O'Donell @ 2005-07-16 20:13 UTC (permalink / raw) To: John David Anglin; +Cc: tausq, parisc-linux On Sat, Jul 16, 2005 at 03:48:10PM -0400, John David Anglin wrote: > > 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. 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 parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-16 20:13 ` Carlos O'Donell @ 2005-07-16 20:29 ` John David Anglin 2005-07-16 21:18 ` Carlos O'Donell 0 siblings, 1 reply; 15+ messages in thread From: John David Anglin @ 2005-07-16 20:29 UTC (permalink / raw) To: Carlos O'Donell; +Cc: tausq, parisc-linux > 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. I guess clobbering all the fp registers plus r0 will stop this. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-16 20:29 ` John David Anglin @ 2005-07-16 21:18 ` Carlos O'Donell 2005-07-16 22:55 ` John David Anglin 0 siblings, 1 reply; 15+ messages in thread From: Carlos O'Donell @ 2005-07-16 21:18 UTC (permalink / raw) To: John David Anglin; +Cc: tausq, parisc-linux On Sat, Jul 16, 2005 at 04:29:54PM -0400, John David Anglin wrote: > > 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. > > 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 parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression). 2005-07-16 21:18 ` Carlos O'Donell @ 2005-07-16 22:55 ` John David Anglin 0 siblings, 0 replies; 15+ messages in thread From: John David Anglin @ 2005-07-16 22:55 UTC (permalink / raw) To: Carlos O'Donell; +Cc: tausq, parisc-linux > > 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 -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [parisc-linux] TLS toolchain update (6 regressions left) 2005-07-15 14:26 [parisc-linux] TLS toolchain update (6 regressions left) Carlos O'Donell 2005-07-15 23:44 ` [parisc-linux] Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression) Carlos O'Donell @ 2005-07-17 16:21 ` Carlos O'Donell 1 sibling, 0 replies; 15+ messages in thread From: Carlos O'Donell @ 2005-07-17 16:21 UTC (permalink / raw) To: John David Anglin, Randolph Chung, parisc-linux On Fri, Jul 15, 2005 at 10:26:10AM -0400, Carlos O'Donell wrote: > 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 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 parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2005-07-17 16:21 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-07-15 14:26 [parisc-linux] TLS toolchain update (6 regressions left) Carlos O'Donell 2005-07-15 23:44 ` [parisc-linux] Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression) Carlos O'Donell 2005-07-16 0:08 ` [parisc-linux] " John David Anglin 2005-07-16 0:57 ` Carlos O'Donell 2005-07-16 1:14 ` Carlos O'Donell 2005-07-16 1:54 ` John David Anglin 2005-07-16 18:38 ` Carlos O'Donell 2005-07-16 19:15 ` John David Anglin 2005-07-16 19:16 ` Carlos O'Donell 2005-07-16 19:48 ` John David Anglin 2005-07-16 20:13 ` Carlos O'Donell 2005-07-16 20:29 ` John David Anglin 2005-07-16 21:18 ` Carlos O'Donell 2005-07-16 22:55 ` John David Anglin 2005-07-17 16:21 ` [parisc-linux] TLS toolchain update (6 regressions left) Carlos O'Donell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.