* [parisc-linux] [RFC] Updated glibc 2.3.5-8.1
@ 2006-01-08 3:03 Carlos O'Donell
2006-01-08 19:03 ` [parisc-linux] " John David Anglin
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Carlos O'Donell @ 2006-01-08 3:03 UTC (permalink / raw)
To: parisc-linux; +Cc: Randolph Chung
Updated glibc 2.3.5-8.1
Contains the following extra fixes:
- Added relocation support for:
= DIR21L, DIR14R, PLABEL21L, PLABEL21R.
- Fixed return value restore in syscall cancellation
- Probably messed up fpu code but made it more compliant
with the fr0 save/restore of T-bit.
- Removed implied routines for 128-bit long double, default
should be whatever gcc uses for long double (DFmode).
Update located:
http://www.parisc-linux.org/~carlos/glibc-work/glibc-2.3.5-debs-2006-01-07/
I have this running on my local system without problems.
I'm testing the NPTL/TLS toolchain using this as my system libc.
Dave could you please test if this fixes the strtold failures?
This is probably the patch set I will send upstream.
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] 8+ messages in thread* [parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1 2006-01-08 3:03 [parisc-linux] [RFC] Updated glibc 2.3.5-8.1 Carlos O'Donell @ 2006-01-08 19:03 ` John David Anglin 2006-01-08 19:13 ` John David Anglin 2006-01-22 16:12 ` [parisc-linux] " Joel Soete 2006-02-04 0:11 ` [parisc-linux] " John David Anglin 2 siblings, 1 reply; 8+ messages in thread From: John David Anglin @ 2006-01-08 19:03 UTC (permalink / raw) To: Carlos O'Donell; +Cc: parisc-linux, tausq > I have this running on my local system without problems. > I'm testing the NPTL/TLS toolchain using this as my system libc. > > Dave could you please test if this fixes the strtold failures? Here are the before and after results: http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00364.html http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00386.html It looks like all the strtold failures in the libstdc++ tests are fixed. However, we have some new failures: FAIL: gfortran.fortran-torture/execute/power.f90 execution, -O0 FAIL: gfortran.fortran-torture/execute/power.f90 execution, -O1 FAIL: gfortran.fortran-torture/execute/power.f90 execution, -O2 FAIL: gfortran.fortran-torture/execute/power.f90 execution, -O3 -fomit-frame-pointer FAIL: gfortran.fortran-torture/execute/power.f90 execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gfortran.fortran-torture/execute/power.f90 execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gfortran.fortran-torture/execute/power.f90 execution, -O3 -g FAIL: gfortran.fortran-torture/execute/power.f90 execution, -Os FAIL: 26_numerics/complex/13450.cc execution test There are also some other changes in the gfortran tests (header optimization issues?). I've looked at 6_numerics/complex/13450.cc at bit: strace ./13450.xg ... mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40003000 --- SIGFPE (Floating point exception) @ 0 (0) --- +++ killed by SIGFPE (core dumped) +++ (gdb) r Starting program: /home/dave/gnu/gcc-4.0/objdir/hppa-linux/libstdc++-v3/testsuite/13450.xg Program received signal SIGFPE, Arithmetic exception. 0x407efaa8 in __ieee754_expf (x=1.62841105) at ../sysdeps/ieee754/flt-32/e_expf.c:95 95 ../sysdeps/ieee754/flt-32/e_expf.c: No such file or directory. in ../sysdeps/ieee754/flt-32/e_expf.c Current language: auto; currently c (gdb) bt #0 0x407efaa8 in __ieee754_expf (x=1.62841105) at ../sysdeps/ieee754/flt-32/e_expf.c:95 #1 0x407f96ec in __cexpf (x=The value of variable 'x' is distributed across several locations, and GDB cannot access its value. ) at ../sysdeps/generic/s_cexpf.c:41 #2 0x407fb5e8 in __cpowf (c=The value of variable 'c' is distributed across several locations, and GDB cannot access its value. ) at ../sysdeps/generic/s_cpowf.c:28 #3 0x0001dba8 in test01_do<float> (a=-3.20000005, b=Cannot access memory at address 0x4 ) at complex:966 #4 0x0001e13c in test01 () at /home/dave/gnu/gcc-4.0/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc:54 #5 0x0001e13c in test01 () at /home/dave/gnu/gcc-4.0/gcc/libstdc++-v3/testsuite/26_numerics/complex/13450.cc:54 Previous frame identical to this frame (corrupt stack?) (gdb) disass 0x407efa88 0x407efac8 Dump of assembler code from 0x407efa88 to 0x407efac8: 0x407efa88 <__ieee754_expf+108>: b,l 0x407ce1cc <__ieee754_acos+5136>,rp 0x407efa8c <__ieee754_expf+112>: ldi 0,r26 0x407efa90 <__ieee754_expf+116>: addil -1000,r4,%r1 0x407efa94 <__ieee754_expf+120>: ldw 51c(,r1),r20 0x407efa98 <__ieee754_expf+124>: fldw 0(,r20),fr22 0x407efa9c <__ieee754_expf+128>: fmpy,sgl fr12,fr22,fr22 0x407efaa0 <__ieee754_expf+132>: addil -1000,r4,%r1 0x407efaa4 <__ieee754_expf+136>: ldw 520(,r1),r20 0x407efaa8 <__ieee754_expf+140>: fldw 0(,r20),fr23 0x407efaac <__ieee754_expf+144>: fadd,sgl fr22,fr23,fr25 0x407efab0 <__ieee754_expf+148>: fsub,sgl fr25,fr23,fr25 0x407efab4 <__ieee754_expf+152>: fcnvff,sgl,dbl fr12,fr24 0x407efab8 <__ieee754_expf+156>: fcnvff,sgl,dbl fr25,fr23 0x407efabc <__ieee754_expf+160>: addil -1000,r4,%r1 0x407efac0 <__ieee754_expf+164>: ldw 524(,r1),r20 0x407efac4 <__ieee754_expf+168>: fldd 0(,r20),fr22 End of assembler dump. (gdb) p/x $r20 $2 = 0x40835264 (gdb) x/x 0x40835264 0x40835264 <M_LN2___5+12>: 0x4b400000 I suspect a kernel or gdb issue wrt the floating-point exception registers: (gdb) info reg all ... mpsfu_high 0x0 0 mpsfu_low 0x0 0 mpsfu_ovflo 0x0 0 pad 0x0 0 fpsr 0x0 0 fpe1 0x0 0 fpe2 0x0 0 fpe3 0x0 0 fpe4 0x0 0 fpe5 0x0 0 fpe6 0x0 0 fpe7 0x0 0 The operands for the previous fmpy insn seem ok. It's interesting that when I single step from the fmpy that I don't see the result in fr22 until after the SIGFPE. It sort of looks like the exception must be in __ieee754_acos. 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] 8+ messages in thread
* [parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1 2006-01-08 19:03 ` [parisc-linux] " John David Anglin @ 2006-01-08 19:13 ` John David Anglin 2006-01-17 20:23 ` Carlos O'Donell 0 siblings, 1 reply; 8+ messages in thread From: John David Anglin @ 2006-01-08 19:13 UTC (permalink / raw) To: John David Anglin; +Cc: carlos, parisc-linux, tausq > in fr22 until after the SIGFPE. It sort of looks like the exception > must be in __ieee754_acos. Take that back. The function calls feholdexcept (envp=0xc04fba68) and then fesetround (round=0) before the arithmetic exception. (gdb) p/x *envp $2 = {__status_word = 0x1, __exception = {0x40000360, 0x1, 0x40000360, 0x4033af90, 0x4084c6b8, 0x4084c6b8, 0x0}} 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] 8+ messages in thread
* [parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1 2006-01-08 19:13 ` John David Anglin @ 2006-01-17 20:23 ` Carlos O'Donell 2006-01-17 20:48 ` John David Anglin 0 siblings, 1 reply; 8+ messages in thread From: Carlos O'Donell @ 2006-01-17 20:23 UTC (permalink / raw) To: John David Anglin; +Cc: parisc-linux, tausq On Sun, Jan 08, 2006 at 02:13:03PM -0500, John David Anglin wrote: > > in fr22 until after the SIGFPE. It sort of looks like the exception > > must be in __ieee754_acos. > > Take that back. The function calls feholdexcept (envp=0xc04fba68) > and then fesetround (round=0) before the arithmetic exception. > > (gdb) p/x *envp > $2 = {__status_word = 0x1, __exception = {0x40000360, 0x1, 0x40000360, > 0x4033af90, 0x4084c6b8, 0x4084c6b8, 0x0}} There could be problems here. I noted in the release email that the FPU stuff is not working well with the new compiler. I need to debug this. If you can find a testcase then it would rock e.g. feholdexcept and fesetround that doesn't set the right bits. I'm glad teh libstdc++ tests are passing. 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] 8+ messages in thread
* [parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1 2006-01-17 20:23 ` Carlos O'Donell @ 2006-01-17 20:48 ` John David Anglin 2006-01-17 21:21 ` Carlos O'Donell 0 siblings, 1 reply; 8+ messages in thread From: John David Anglin @ 2006-01-17 20:48 UTC (permalink / raw) To: Carlos O'Donell; +Cc: parisc-linux, tausq > On Sun, Jan 08, 2006 at 02:13:03PM -0500, John David Anglin wrote: > > > in fr22 until after the SIGFPE. It sort of looks like the exception > > > must be in __ieee754_acos. > > > > Take that back. The function calls feholdexcept (envp=0xc04fba68) > > and then fesetround (round=0) before the arithmetic exception. > > > > (gdb) p/x *envp > > $2 = {__status_word = 0x1, __exception = {0x40000360, 0x1, 0x40000360, > > 0x4033af90, 0x4084c6b8, 0x4084c6b8, 0x0}} > > There could be problems here. I noted in the release email that the FPU > stuff is not working well with the new compiler. I need to debug this. > If you can find a testcase then it would rock e.g. feholdexcept > and fesetround that doesn't set the right bits. Randolph has a patch which he sent around a few days ago. The problem appears to be a sequencing issue with respect to fr0. He dropped saving and restoring fr1, fr2 and fr3. Debian may be going to roll an hppa libc update in the near future. It would be nice to also get your other fixes into this update as well. As I understand it, the exception bug causes a segmentation fault in uic. This blocks building qt-xfree86-free which blocks kde. Thus, the issue is quite urgent. 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] 8+ messages in thread
* Re: [parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1 2006-01-17 20:48 ` John David Anglin @ 2006-01-17 21:21 ` Carlos O'Donell 0 siblings, 0 replies; 8+ messages in thread From: Carlos O'Donell @ 2006-01-17 21:21 UTC (permalink / raw) To: John David Anglin; +Cc: tausq, parisc-linux On Tue, Jan 17, 2006 at 03:48:51PM -0500, John David Anglin wrote: > > On Sun, Jan 08, 2006 at 02:13:03PM -0500, John David Anglin wrote: > > > > in fr22 until after the SIGFPE. It sort of looks like the exception > > > > must be in __ieee754_acos. > > > > > > Take that back. The function calls feholdexcept (envp=0xc04fba68) > > > and then fesetround (round=0) before the arithmetic exception. > > > > > > (gdb) p/x *envp > > > $2 = {__status_word = 0x1, __exception = {0x40000360, 0x1, 0x40000360, > > > 0x4033af90, 0x4084c6b8, 0x4084c6b8, 0x0}} > > > > There could be problems here. I noted in the release email that the FPU > > stuff is not working well with the new compiler. I need to debug this. > > If you can find a testcase then it would rock e.g. feholdexcept > > and fesetround that doesn't set the right bits. > > Randolph has a patch which he sent around a few days ago. The > problem appears to be a sequencing issue with respect to fr0. > He dropped saving and restoring fr1, fr2 and fr3. Debian may be > going to roll an hppa libc update in the near future. It would > be nice to also get your other fixes into this update as well. Yes, I saw that patch, but Randolph didn't say why it fixes the issue. There *was* a sequencing issue wrt to fr1,2,3 but we fixed that in CVS. You have to restore fr0 last, and save it first, it's not an impossible task :) > As I understand it, the exception bug causes a segmentation fault > in uic. This blocks building qt-xfree86-free which blocks kde. > Thus, the issue is quite urgent. That is a bummer. I'll post my debian patches soon then. 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] 8+ messages in thread
* Re: [parisc-linux] [RFC] Updated glibc 2.3.5-8.1 2006-01-08 3:03 [parisc-linux] [RFC] Updated glibc 2.3.5-8.1 Carlos O'Donell 2006-01-08 19:03 ` [parisc-linux] " John David Anglin @ 2006-01-22 16:12 ` Joel Soete 2006-02-04 0:11 ` [parisc-linux] " John David Anglin 2 siblings, 0 replies; 8+ messages in thread From: Joel Soete @ 2006-01-22 16:12 UTC (permalink / raw) To: Carlos O'Donell; +Cc: Randolph Chung, parisc-linux Carlos O'Donell wrote: > Updated glibc 2.3.5-8.1 > > Contains the following extra fixes: > > - Added relocation support for: > = DIR21L, DIR14R, PLABEL21L, PLABEL21R. > > - Fixed return value restore in syscall cancellation > > - Probably messed up fpu code but made it more compliant > with the fr0 save/restore of T-bit. > > - Removed implied routines for 128-bit long double, default > should be whatever gcc uses for long double (DFmode). > > Update located: > http://www.parisc-linux.org/~carlos/glibc-work/glibc-2.3.5-debs-2006-01-07/ > mmm, isn't it possible to add your .diff.gz (may be also .dsc), that would help me a lot to countinue my test with gcc-4.0 ;-) [...] > > This is probably the patch set I will send upstream. > TIA, Joel _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 8+ messages in thread
* [parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1 2006-01-08 3:03 [parisc-linux] [RFC] Updated glibc 2.3.5-8.1 Carlos O'Donell 2006-01-08 19:03 ` [parisc-linux] " John David Anglin 2006-01-22 16:12 ` [parisc-linux] " Joel Soete @ 2006-02-04 0:11 ` John David Anglin 2 siblings, 0 replies; 8+ messages in thread From: John David Anglin @ 2006-02-04 0:11 UTC (permalink / raw) To: Carlos O'Donell; +Cc: parisc-linux, tausq Hi Carlos, > - Removed implied routines for 128-bit long double, default > should be whatever gcc uses for long double (DFmode). There have been a continual stream of patches on the GCC list trying to fix the 128-bit long-double support for powerpc, etc. This seems to be some sort of requirement for glibc 2.4. The arches supported by Red Hat are trying to get this into GCC 4.1. Is this something we need to do right now? See comment here: http://gcc.gnu.org/ml/gcc/2006-02/msg00089.html. 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] 8+ messages in thread
end of thread, other threads:[~2006-02-04 0:11 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-01-08 3:03 [parisc-linux] [RFC] Updated glibc 2.3.5-8.1 Carlos O'Donell 2006-01-08 19:03 ` [parisc-linux] " John David Anglin 2006-01-08 19:13 ` John David Anglin 2006-01-17 20:23 ` Carlos O'Donell 2006-01-17 20:48 ` John David Anglin 2006-01-17 21:21 ` Carlos O'Donell 2006-01-22 16:12 ` [parisc-linux] " Joel Soete 2006-02-04 0:11 ` [parisc-linux] " John David Anglin
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.