Re: [GP/PARI] 2.0.21 bug in exp()?

[Gerhard Niklasch <gerhard.niklasch@germany.sun.com>]

In response to:
> Message-Id: <200011150058.TAA19857@grail.cba.csuohio.edu>
> Date: Tue, 14 Nov 2000 19:58:25 -0500
> From: Michael Somos <somos@grail.cba.csuohio.edu>
> To: pari-dev@list.cr.yp.to
> Subject: [GP/PARI] 2.0.21 bug in exp()?
> 
> I just ran across a problem which I can't overcome. I downloaded
> the 2.0.21 and tried the following simple function :
...
> gp> f(x,d=10,v=0)=
> {
>   local(rc);
> /*DEB*/ if(v,print("f("x","d")"));
>   rc=
>   if(x<=0, error("only positive allowed in f()"),
>   if(d<0, error("recur depth positive"),
>   if(x==1|d==0, 0,
>   if(x<1, -f(1/x,d-1,v),
>   /*x>1*/ exp(f(x-1,d-1,v))
>   ))));
> /*DEB*/ if(v,print("f("x","d")="rc));
>   rc;
> } /* end f() */
> gp> f(16/5,8,1)
...
> f(11/5,7)=1.000000000000000000000000000
> 
> At this point the system seems to hang for a long long time. I can only
> guess that the bug may be in exp() somehow. Who knows? Shalom, Michael

Confirmed here with the current CVS version (Sun cc, Solaris 7 / sparc):
looks like a long (or infinite) loop, or of something getting called
with a wrong argument -- the inner end of the stack trace of the running
process is:

 ff09cb70 ???????? (ff2fb334, ff2fb338, f8003a23, fc338, 1abc28, b29)
 ff203108 mpexp1   (800000, ffffff, 101c88, 251c38, 101c88, ff000000) + 360
 ff203670 gexp     (3a1b18, 5, 0, 0, 0, 3a1b18) + 104
 ff280c8c identifier (ff2d8a60, ff2c0ab0, ff30c6fc, 0, ff20356c, 0) + 1534
 ff27b2d8 truc     (ff2c0800, 65, 6b9b1, 4a9c14, 6b9b1, ff2c0ab0) + 3ec
 ff27aab0 facteur  (5dca4, ff18d338, ff2c0ab0, 1, 4a9c14, ff18d000) + 38
 ff279c40 expr     (ff2c0800, 65, 4a9c14, 6b9b1, 16d441, ff18d428) + 104
 ff279a14 seq      (ff2c0800, 2c, 4a9c13, 449a74, 16d441, 261652) + 88

the function called by mpexp1 turns out to be:

0xff203108: mpexp1+0x0360:      call    mulrr

and this is the first mulrr call from mpexp1:
===8<---
  s=0; l1=4; av2 = avma;
  for (i=n; i>=2; i--)
  {
    setlg(p4,l1); p3 = divrs(p4,i);
    s -= expo(p3); p1 = mulrr(p3,p2); setlg(p1,l1); /* <<<<<< */
    l1 += s>>TWOPOTBITS_IN_LONG; if (l1>l2) l1=l2;
    s %= BITS_IN_LONG;
    setlg(unr,l1); p1 = addrr(unr,p1);
    setlg(p2,l1); affrr(p1,p2); avma = av2;
  }
--->8===

But ff09cb70 is wayyyyy beyond mulrr, it would correspond to
mpsqrtl+0x01c8 in my binary, so the C stack may have be corrupted.

(Karim, is this another incarnation of the recent problem with the
shift macros...?)

Puzzled, Gerhard