On Sat, Oct 11, 2014 at 03:14:26PM -0400, John David Anglin wrote: > Package: libmath-int64-perl > Version: 0.32-1 > Severity: normal > > t/Math-Int64-Native.t ... ok > > # Failed test 'max int64 >> 63' > # at t/Math-Int64.t line 175. > # got: '0' > # expected: '1' > > # Failed test 'max int64 >>= 63' > # at t/Math-Int64.t line 179. > # got: '0' > # expected: '1'
Thanks! I had a look on s390x, which is also failing. This is a new test rather than a functionality regression. A standalone test is % perl -MMath::Int64=int64 -le 'print "ok" if 0 == ((((int64(2)**62)-1)*2)+1)/(2**63)' which divides an integer 2**63-1 with a "regular" 2**63 and expects 0 as a result because the former is smaller. I think this is a floating point accuracy issue: 2**63 ends up as a floating point variable by default, and perl -MMath::Int64=int64 -le 'print int64(2)**63 - 2**63' gives 1 on s390x but 0 on amd64. So the regular 2**63 seems to be actually 2**63-1 on s390x (and probably the other failing architectures as well.) Now, on Debian it's possible to express 2**63 as a Perl integer as we're configuring with -Duse64bitint, and indeed perl -MMath::Int64=int64 -le 'print int64(2)**63 - int(2**63)' gives 0 on both amd64 and s390x, and perl -MMath::Int64=int64 -le 'print "ok" if 0 == ((((int64(2)**62)-1)*2)+1)/int(2**63)' gives 'ok' on both. However, that's really just a workaround: Math::Int64 is redundant on -Duse64bitint systems anyway so I assume the real target is systems with 32-bit Perl integers, where I don't expect the int() cast to help at all. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
