Re: GMP 4.1 on Solaris, HP-UX ... hppa1.1

[Albert Chin]

On Sat, Jun 01, 2002 at 09:01:21AM +1000, Kevin Ryde wrote:
> Albert Chin <address@hidden> writes:
> >
> > Ok, the patch below fixes 13 of the failures. The patch forces ".level
> > 1.1" in the ASM files.
> 
> What's the reason for that?

Because of the following error when using (unpatched copy of GMP 4.1):
  $ uname -a
  HP-UX flash B.10.20 A 9000/782 2013055757 two-user license
  $ ABI=standard CC=cc CFLAGS="-g -Ae +DAportable" \
  ./configure --enable-shared --enable-static \
  --disable-dependency-tracking --host=hppa1.1-hp-hpux10.20
  /bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" cc
  -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I..
  -DOPERATION_`echo submul_1 | sed 's/_$//'`    -g -Ae +DAportable `test
  -f submul_1.asm || echo './'`submul_1.asm
  ../mpn/m4-ccas --m4=m4 cc -c -DHAVE_CONFIG_H -I. -I. -I..
  -D__GMP_WITHIN_GMP -I.. -DOPERATION_submul_1 -g -Ae +DAportable
  submul_1.asm  +Z -DPIC -o .libs/submul_1.o
  m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_submul_1 -DPIC
  submul_1.asm >tmp-submul_1.s
   cc -c -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I..
  -DOPERATION_submul_1 -g -Ae +DAportable tmp-submul_1.s +Z -DPIC -o
  .libs/submul_1.o
  as: "tmp-submul_1.s", line 70: warning 36: Use of %fr31R is incorrect
  for the current LEVEL of 1.0
  as: "tmp-submul_1.s", line 83: warning 36: Use of %fr31R is incorrect
  for the current LEVEL of 1.0
  as: "tmp-submul_1.s", line 83: warning 36: Use of XMPYU is incorrect
  for the current LEVEL of 1.0
  as: "tmp-submul_1.s", line 97: warning 36: Use of %fr31R is incorrect
  for the current LEVEL of 1.0
  ...
  $ cd mpn
  $ ls -ld submul_1.asm
  lrwxrwxr-x   1 china      src             41 Jun  3 06:34 submul_1.asm
  -> .././mpn/pa32/hppa1_1/pa7100/submul_1.asm

So, even though this is a PA-RISC 2.0 machine, I bumped .level to 1.1
thinking of the "1.1" in hppa1.1-hp-hpux10.20.

> > The remaining failure is the coredump in
> > t-sizeinbase. A GDB backtrace follows:
> >   #0  0xc07979e4 in __gmpz_sizeinbase (x=0x7b03a908, base=2)
> >       at sizeinbase.c:32
> >   #1  0x296c in mpz_fake_bits (z=0x7b03a908, totbits=198096465)
> >       at t-sizeinbase.c:45
> >   #2  0x2a0c in check_sample () at t-sizeinbase.c:64
> >   #3  0x2b0c in main () at t-sizeinbase.c:83
> 
> Hmm.  That mpz_fake_bits in the test program doesn't do normal mpz
> stuff, but is supposed to be enough to satisfy the accesses
> mpz_sizeinbase makes.
> 
> > -    path="pa32/hppa1_1/pa7100 pa32/hppa1_1 pa32"
> > +    path="pa32/hppa1_1 pa32"
> 
> I guess we've got hppa1.1 meaning 7100 effectively.

I took the pa7100 path out because of the following in configure.in:
  # FIXME: path should be "pa32/hppa2_0 pa32/hppa1_1 pa32"
  path="pa32/hppa2_0 pa32/hppa1_1/pa7100 pa32/hppa1_1 pa32"

> > +      hppa1.1*-*-*)
> > +        abilist="1.1 $abilist"
> 
> No, 1.1 isn't an abi, not unless I badly misunderstand something about
> hppa.

I was probably wrong. I should probably leave the ABI as "standard"
but set .level 1.1 in the asm files. I just thought the 1.1 ABI came
from PA-RISC 1.1 processors.

-- 
albert chin (address@hidden)