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 nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
