zeta() bug?

[Michael Somos <somos@grail.cba.csuohio.edu>]

Prompted by Igor Schein's recent message about zeta() I did a bit of
experimenting and found the following ( with a weeks old version )

Type ? for help, \q to quit.
Type ?12 for how to get moral (and possibly technical) support.

   realprecision = 28 significant digits
   seriesprecision = 16 significant terms
   format = g0.28

parisize = 4000000, primelimit = 500000
gp> \v
                GP/PARI CALCULATOR Version 2.0.18 (development)
                i686 running linux (ix86 kernel) 32-bit version
              (readline v2.2 enabled, extended help not available)
gp> zeta(599065705248735807.99999999999999999)
  ***   exponent too large in exp.

gp> print(zeta(599065705248735807.99999999999999999))
  ***   exponent too large in exp.

gp> zeta(599065705248735808.00000000000000000)
  ***   bug in multiplication, please report
gp> print(zeta(599065705248735808.00000000000000000))
  ***   segmentation fault: bug in GP (please report).


However, when I downloaded via CVS an up-to-the-minute version I got

gp> \v
                    GP/PARI CALCULATOR Version 2.0.18 (beta)
                i686 running linux (ix86 kernel) 32-bit version
                (readline v2.2 enabled, extended help available)
gp> zeta(599065705248735807.99999999999999999)
  ***   exponent too large in exp.

gp> print(zeta(599065705248735807.99999999999999999))
  ***   exponent too large in exp.

gp> zeta(599065705248735808.00000000000000000)
%1 = 0.5000000000000000016692659774
gp> print(zeta(599065705248735808.00000000000000000))
0.5000000000000000016692659774

Which is a bit different. I guess the "bug in multiplication" got
fixed, but the answer is still wrong I think. However, I am not sure
what "bug in multiplication" is supposed to mean, and why furthermore
the "print(zeta(...))" in that case got a sementation fault. It seems
that zeta() is not such a simple function to compute. There must be
severe problems in extreme cases. Given the PARI philosophy, there are
more severe cases than would usually be the case in an arbitrary
precision calculator. Shalom, Michael