A ha ha, I'm such an idiot  let's again look at your example 's h' selftest error message:
Quote:
Originally Posted by tdulcet
Res mod 2^35  1 = 7270151463
Res mod 2^36  1 = 68679090081
*** Res35m1 Error ***
current = 7270151463
should be = 29128713056
*** Res36m1 Error ***
current = 68679090081
should be = 7270151463

Return with code ERR_INCORRECT_RES64
Error detected  this radix set will not be used.
WARNING: 0 of 10 radixsets at FFT length 65536 K passed  skipping it. PLEASE CHECK YOUR BUILD OPTIONS.

Notice that the 'current' (= from selftest) Res35m1 value matches the 'should be' (= pretabulated reference value) Res36m1 one? Let's have a look at the pretabulated reference residues for this FFT length in Mlucas.c:
{ 65536,1166083297u, { {0xA0FE3066C834E360ull, 29128713056ull, 7270151463ull}, ...
65536K FFT, reference test exponent 1166083297, followed by 3 refresidue triplets, corresponding to the test residue modulo 2^64 (low 64 bits of full residue = Res64, in hex), 2^351 and 2^361. The triplets are for iters 100,1000,10000, I have copied only the 100iter one above.
The residues modulo 2^351 and 2^361 are a.k.a. the SelfridgeHurwitz residues, after the 2 worthies who used them for their Fermatnumber primalitytesting work in the 1960s, on mainframe hardware which supported a 36bit integer type. They also included the residue modulo 2^36, but as that is just the low 36 bits of the GIMPSused Res64, it's redundant. But until a couple years ago, Mlucas would print all 4 residues like so  let's again use the above case to illustrate, since we can trivially extract the Res36 from the Res64:
Code:
Res64: 0xA0FE3066C834E360
Res mod 2^36 = 29128713056
Res mod 2^35  1 = 7270151463
Res mod 2^36  1 = 68679090081
Now it's clear what must've happened  a few years back when I tabulated those 's h' entries, I must've done all the needed runs, assembled the resulting 4line entries as above, then batchedited them. Should've deleted the Res mod 2^36 line and used the remaining 3, but must've instead kept the first 2 decimal residues and deleted the the mod 2^36  1 one in a bunch of cases.
The good news is that that makes it easy to see which tabulated entries are fubar in this manner  just extract the low 9 hexits of the Res64 for each triplet, print in decimal, see if that matches the first of the 2 following 36bit decimal entries in the triplet, if so, it's fubar.
Per that, for the 100iter triplets, all but last 3 need redo  but those 3, for FFT lengths 212992,229376,245760  should be OK. Further, none of the 1000iter reference triplets show the above 'whoops', so those should all be OK.
But I see I never got around to filling in the 10000iter table entries for these large FFT lengths, so since the 100 and 1000iter are pretty fast to recompute compared to those, gonna redo them all.