Bug#577016: perl: FTBFS (experimental/sparc): -Duse64bitint problems?

[Niko Tyni]

On Fri, Apr 16, 2010 at 09:57:23PM +0300, Niko Tyni wrote:
> On Fri, Apr 09, 2010 at 09:29:23AM +0300, Niko Tyni wrote:
> > On Fri, Apr 09, 2010 at 01:05:08AM +0300, Niko Tyni wrote:
> > > Package: perl
> > > Version: 5.12.0~rc3-1
> > > Severity: important
> > > 
> > > The sparc build had other test failures besides the CPANPLUS ones
> > > (#577011):
> > > 
> > >     ../cpan/bignum/t/bigexp.t
> > >     op/numconvert.t
> > >     op/pack.t
> > >     op/pow.t
> > 
> > > I think the first thing to try is to turn off the new -Duse64bitint
> > > just for sparc.
> > 
> > Testing on smetana.d.o confirms these are indeed caused by the
> > -Duse64bitint setting.
> 
> It turns out that setting uselongdouble too (known together as
> usemorebits) makes the failures go away on smetana, so that's what I
> intend to try for 5.12.0-1.

The discussion on debian-devel has just about sold me on use64bitint
without uselongdouble for all architectures. 

 http://lists.debian.org/debian-devel/2010/05/msg00078.html

However, this bug is a blocker for that and I doubt there's an easy
way out.

The failure in t/op/pow.t is because (in C-speak)
 (double)pow(2,56) - ((long long)1 << 56) != 0
on sparc. 

There's nothing particularly wrong with that, but the test checks
exponents up to the full number of integer bits (64 in this case) because
(quoting):

 # Unfortunately rather a lot of perl programs expect 2 ** $n to be integer
 # perfect, forgetting that it's a call to floating point pow() which never
 # claims to deliver perfection.


At least the first failures in op/numconvert.t are demonstrated by

smetana% ./perl -Ilib -MDevel::Peek -e '$n=979797979797979797; Dump $n; $n="$n"; Dump $n; printf("%g\n", $n)' 
SV = IV(0x4f3470) at 0x4f3470
  REFCNT = 1
  FLAGS = (IOK,pIOK)
  IV = 979797979797979797
SV = PVIV(0x4ea6e0) at 0x4f3470
  REFCNT = 1
  FLAGS = (POK,pPOK)
  IV = 979797979797979797
  PV = 0x5000b0 "979797979797979797"\0
  CUR = 18
  LEN = 20
2.47804e+18

which looks like a real bug in printf() to me.

As for op/pack.t:

not ok 240 - Round trip pack, unpack 'w' of 8.98846567431158e+307 is within 1% (inf%)

the unpacked and packed result substraction overflows:

smetana% ./perl  -Ilib -MDevel::Peek -le '$in=8.98846567431158e+307; $out=unpack("w", pack("w", $in)); Dump $in; Dump $out; print $in - $out'
SV = NV(0x5102c0) at 0x4f34a0
  REFCNT = 1
  FLAGS = (NOK,pNOK)
  NV = 8.98846567431158e+307
SV = PV(0x4d77f8) at 0x4f3500
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x4fc2f8 "89884656743115835303271450233847469808353109683886649985740249288017167953695330310592076040485083709719366792649718465678331768257113190695183483191610276972319912409061149038264568822336577410480970363302246537486210232049711307353165657687821396358780624303176299262391760484360690999587582771692310626304"\0
  CUR = 308
  LEN = 312
-inf

The failing part seems to be string to numeric conversion.

Finally, cpan/bignum/t/bigexp.t:

not ok 1 - ($ev) is approx. 1
#   Failed test '($ev) is approx. 1'
#   at cpan/bignum/t/bigexp.t line 22.
#          got: '2.55885'
#     expected: '1.00000'

a stand-alone test is

./perl -Mbignum   -Ilib  -e '$a=exp(-.1); printf("%s\n%f\n", $a,$a)';
0.9048374180359595731642490594464366211947
2.178198

which seems printf-related again.

Will forward this upstream after some more tests.
-- 
Niko Tyni   ntyni at debian.org