[parisc-linux] [RFC] Updated glibc 2.3.5-8.1

[parisc-linux] [RFC] Updated glibc 2.3.5-8.1

[Carlos O'Donell]

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

[parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1

[John David Anglin]

> 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

[parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1

[John David Anglin]

> 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

[parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1

[Carlos O'Donell]

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

[parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1

[John David Anglin]

> 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

Re: [parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1

[Carlos O'Donell]

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

Re: [parisc-linux] [RFC] Updated glibc 2.3.5-8.1

[Joel Soete]

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

[parisc-linux] Re: [RFC] Updated glibc 2.3.5-8.1

[John David Anglin]

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