Bug#764874: libmath-int64-perl: FTBFS on hppa and others: test fails

[Niko Tyni]

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   ntyni at debian.org