Thanks. Bisecting the changes is probably a better method, but just in case I took a look at my code.
The issues shows up in BoldiVigna.pm put_boldivigna in the case of encoding ~0-2 followed by 0, where the problem shows up with the 0.
$v = 0
$hk = 0
my $x = $v - (1 << $hk) + 1;
should yield $x = 0 but instead $x = 1.84467440737095516e+19.
Using Devel::Peek with 5.23.2 and 5.23.5:
v is an IV with READONLY flag
hk is an NV (IV=0, NV=0, PV=0)
x was an IV (IV=0)
x is now an NV (IV=-4611686018427387906, NV=1.84467440737095516e+19, PV=0)
Because this doesn't show up with either number encoded by itself, and on the previous call $hk was 62, I have a suspicion that we're somehow using the old value of the lexical variable $hk. 0 - (1 << 62) + 1 is within rounding of the new value.
Changing the line to:
my $x = ($hk == 0) ? $v : $v - (1 << $hk) + 1;
makes it work. If things were working correctly, this wouldn't matter.
It looks like Math::Prime::Util's pure Perl invmod() also has an issue with the new perl:
MPU_NO_XS=1 perl -Iblib/lib -Iblib/arch -Mntheory=:all -E 'say invmod(13, 9223372036854775808); say invmod(14,18446744073709551615)'
5675921253449092805
17129119497016012214
has the last result wrong with 5.23.5. Again this is a case where running one invmod by itself is fine, but two in a row gets things wrong. Something is perhaps not getting initialized?
