Bug#708264: gmp: mpn_sqrtrem is broken on ia64

[Bill Allombert]

On Tue, May 14, 2013 at 12:04:41PM -0500, Steve M. Robbins wrote:
> On Tue, May 14, 2013 at 06:44:50PM +0200, Bill Allombert wrote:
> > On Tue, May 14, 2013 at 11:19:52AM -0500, Steve M. Robbins wrote:
> > > On Tue, May 14, 2013 at 05:20:35PM +0200, Bill Allombert wrote:
> > > > Package: libgmp10
> > > > Version: 2:5.1.1+dfsg-3
> > > > Severity: important
> > > > 
> > > > Dear maintainers,
> > > > 
> > > > On ia64 it seems that mpn_sqrtrem fails to preserve the hardware registers,
> > > > leading to difficult to track down bugs.
> > > > 
> > > > Please see the attached file.
> > > > on merulo.debian.org running sid (gcc is 4.6.3-15)
> > > 
> > > A quick question: is merulo realy ia64 hardware or is it emulated?  I
> > > ask because gmp has issues with the kvm emulation of some hardware.
> > > If you have access to physical hardware (I don't), can you run your
> > > test there, please?
> > 
> > I can only perform the test in a schroot of merulo which is probably using some
> > kind of virtualization. However the real buildd are probably using the same
> > kind of virtualization.
> > 
> > Alas I do not think I have access to any non-Debian ia64 anymore.
> 
> Hmm.  That's too bad.  Maybe one of the ia64 porters has real hardware.

Do you have a link to the kvm issue ? I do not think this is relevant to this
bug.

As far as I see, removing the file 'mpn/ia64/divrem_2.asm' from the source
fix this bug. Indeed this file change f16,f17 and f18 but the file
mpn/ia64/README says 

       REGISTER USAGE
       
       Special:
          r0: constant 0
          r1: global pointer (gp)
          r8: return value
          r12: stack pointer (sp)
          r13: thread pointer (tp)
       Caller-saves: r8-r11 r14-r31 f6-f15 f32-f127
       Caller-saves but rotating: r32-

So f16,f17 and f18 are not a priori assumed Caller-saves and I see nothing to
restore them in mpn/ia64/divrem_2.asm

With GNU GMP rebuilt without mpn/ia64/divrem_2.asm, PARI works fine.

> On another note: can you turn your test case into a unit test that I can
> add to the build?  I just need a function that returns true if the test
> passes, then I can hook it into the build process to ensure this failure
> does not come back.

This seems difficult to do properly. You need to know what are the register
convention on ia64 and write some assembly code that manually set the registers
and read them back. It happens I noticed f7 was clobbered, so my test case
piles on the float register stack until it reached f17.

Cheers,
Bill.