Re: [PATCH, RFC] Enable IBM long double for PPC32 Linux

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Jan 30, 2006 at 01:35:21PM +0100, Ulrich Weigand wrote:
> Jakub Jelinek wrote:
> 
> > Without these patches it is not possible to compile glibc 2.4 on those
> > architectures and the patches shouldn't have effect on code compiled
> > by default (unless you explicitly use -mlong-double-128).  The only
> > package that would use this switch by default would be glibc, and glibc
> > build can be tested satisfactorily within days (we already build ppc{32,64}
> > glibc that way, are going to do the same with s390{,x} glibc during this
> > weekend), especially because glibc has quite good testsuite.
> 
> Could you let me know how those tests went?  It would be good to have that
> additional confirmation before committing the patch to 4.1 ...

I was testing redhat/gcc-4_1-branch with the patch Andreas posted:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01953.html
and the attached glibc patch (slightly modified from the one he sent me)
on top of CVS glibc.
On s390 -m31 it builds but test-{,i}ldoubl{,e} tests segfault (will look
into it soon) and keep you informed.
On s390x -m64, I'm getting several reload ICEs.  E.g.
int
isinfl(long double x)
{
  long long int hx,lx;

  union
    {
      long double value;
      struct
        {
          long long int msw, lsw;
        } parts64;
    } qw_u;
  qw_u.value = x;
  hx = qw_u.parts64.msw;
  lx = qw_u.parts64.lsw;
  lx |= (hx & 0x7fffffffffffffffLL) ^ 0x7fff000000000000LL;
  lx |= -lx;
  return ~(lx >> 63) & (hx >> 62);
}

LC_ALL=C gcc ldbl.c -m64 -mlong-double-128 -O2 ldbl.c
ldbl.c: In function 'isinfl':
ldbl.c:20: error: unable to find a register to spill in class 'FP_REGS'
ldbl.c:20: error: this is the insn:
(insn 13 32 15 0 (set (subreg:TF (reg/v:TI 4 %r4 [orig:46 qw_u ] [46]) 0)
        (mem/c/i:TF (reg:DI 2 %r2 [ x ]) [2 x+0 S16 A64])) 66 {movtf} (nil)
    (expr_list:REG_DEAD (reg:DI 2 %r2 [ x ])
        (nil)))
ldbl.c:20: confused by earlier errors, bailing out

Haven't tried GCC trunk yet, sorry, working on the libstdc++-v3 bits ATM
and also will be looking into s390 segfaults.  Note that
svn diff svn+ssh://gcc.gnu.org/svn/gcc/branches/{,redhat/}gcc-4_1-branch/gcc/reload.c
svn diff svn+ssh://gcc.gnu.org/svn/gcc/branches/{,redhat/}gcc-4_1-branch/gcc/reload1.c
svn diff svn+ssh://gcc.gnu.org/svn/gcc/branches/{,redhat/}gcc-4_1-branch/gcc/config/s390
yields nothing, so it is very likely at least gcc-4_1-branch has the same problem.

	Jakub

Attachment: R2
Description: Text document