Different results in llr2 1.3.0

[bur]

Thanks! Admittedly, I got LLR2 from the primegrid download folder. I didn't know about the Github.

So just for my peace of mind... :) Can anyone estimate how likely it is, that there's an uncaught bug in software like LLR2 that even with Gerbicz it would wrongly detect a prime as composite?

[Happy5214]

Originally Posted by bur

So the bug is only affecting FMA3 FFT?

The 32-bit llr 4.0.3 code path on AVX is also affected:

$ ./llr -v && ./llr -d -q"1385084*391^3437-1"
LLR Program - Version 4.0.3, using Gwnum Library Version 30.6
Base factorized as : 17*23
Base prime factor(s) taken : 23
Starting N+1 prime test of 1385084*391^3437-1
Using zero-padded AVX FFT length 4K, a = 3
1385084*391^3437-1 may be prime. Starting Lucas sequence...                                        
Using zero-padded AVX FFT length 4K, P = 3
1385084*391^3437-1 is not prime, although Fermat PSP! P = 3, Lucas RES64: CF91244F7FB614D5  Time : 1.271 sec.

[rebirther]

I have compiled llr2 with gwnum30.10b4 on windows but the error is still present without Gerbicz check.

[rebirther]

f:\llr>llr2.exe -d -q"1385084*391^3437-1"
Base factorized as : 17*23
Base prime factor(s) taken : 23
Starting N+1 prime test of 1385084*391^3437-1
Using zero-padded FMA3 FFT length 4K, a = 3
1385084*391^3437-1 may be prime. Starting Lucas sequence...
Using zero-padded FMA3 FFT length 4K, P = 3
1385084*391^3437-1 may be prime, trying to compute gcd's
U((N+1)/23) is coprime to N!
1385084*391^3437-1 is prime! (8916 decimal digits, P = 3)  Time : 1.012 sec.

The latest llr2 is now working with gwnum30.11 without Gerbicz check.