I spent hours looking for a macro for the new MPN_ZERO that gcc 4.1.2 would not miscompile on ia64 and I came to the conclusion one does not exist. That compiler is very broken. I checked the output of the preprocessor was correct, i.e. it wasn't misexpanding the macros. But some kind of expression parser in that version of gcc is subsequently screwing up offset addressing.
To work around this issue, I have simply inserted code in the toom4 and toom4 squaring code which passes make check. Basically MPIR should never be compiled on gcc 4.1.2 as one cannot make any guarantees of correct results. This happens to be the default compiler on SkyNet, but I think they probably use a later gcc whenever possible anyway. Mariah always seems keen to update to the latest gcc. I'm not sure what compiler is used on Cato. Perhaps that is gcc 4.1.2. Then again, maybe this issue is Itanium specific too. Bill. keywords : gcc 4.1.2 MPN_ZERO macro offset addressing t-div f-div make check failure toom4 mpn_toom4_mul_n hack 2009/5/29 Bill Hart <[email protected]>: > I think it is a miscompilation not just of the macro, but that > particular instance of the macro. > > To be safe I think I am going to insert a nasty hack which will use a > for loop instead of a while statement when either the machine is an > ia64 OR the gcc is 4.1.2. I'm very convinced it is a miscompilation > and not a coding bug/programmer's feature. > > Bill. > > 2009/5/29 Jason Moxham <[email protected]>: >> On Friday 29 May 2009 07:30:14 Bill Hart wrote: >>> Apparently that doesn't help. >>> >>> Has the function mpn_store changed for ia64? Could this somehow be >>> what is miscompiled? >> >> The mpn_store macro is just the same as the old MPN_ZERO macro but with a >> value for zero , so MPN_ZERO in mpir-1.1 should also fail somehow. >> >>> >>> It is remarkable that no permutation of things around that line >>> (except compiling without optimisation) seems to cause it to work. >>> >>> Bill. >>> >>> 2009/5/29 Jason Moxham <[email protected]>: >>> > try it as >>> > mpn_store(r3+1,t4-2,0) >>> > >>> > as the new MPN_ZERO is a macro to mpn store >>> > it may help!!! >>> > >>> > On Friday 29 May 2009 00:41:27 Bill Hart wrote: >>> >> I've tracked the bug down to a single line of code: >>> >> >>> >> if (n3 == 0) MPN_ZERO(r3 + 1, t4 - 2); /* Line of broken code*/ >>> >> else TC4_DENORM(r3, n3, t4 - 1); >>> >> if (ic == 18) >>> >> { >>> >> printf("r3[t4 - 2] = %ld\n", r3[t4 - 2]); >>> >> printf("n3 = %ld, t4 = %ld\n", n3, t4); >>> >> } >>> >> >>> >> prints: >>> >> >>> >> r3[t4 - 2] = -6148914691236517206 >>> >> n3 = 0, t4 = 158 >>> >> >>> >> I've tried all the usual sensible things like adding extra parentheses >>> >> and braces. Compiles just fine with -O0 compilation optimization. >>> >> >>> >> Just for kicks, here is the definition of TC4_DENORM: >>> >> >>> >> /* Zero out limbs to end of integer */ >>> >> #define TC4_DENORM(rxx, nxx, sxx) \ >>> >> do { \ >>> >> MPN_ZERO(rxx + ABS(nxx), sxx - ABS(nxx)); \ >>> >> } while (0) >>> >> >>> >> As you see, it cannot touch nxx. >>> >> >>> >> This is surely quite a broken compiler! >>> >> >>> >> Bill. >>> >> >>> >> 2009/5/28 Bill Hart <[email protected]>: >>> >> > Even if I switch on all the compiler optimisations that the man pages >>> >> > say are switched on by -O1 it still passes make check. The diff of the >>> >> > assembly output between the two (-O1 versus all the optimisations it >>> >> > says it uses) for toom4_mul_n.c is about 90,000 lines!! This is just >>> >> > stupid. How is one supposed to fix bugs like this!? >>> >> > >>> >> > Bill. >>> >> > >>> >> > 2009/5/28 Bill Hart <[email protected]>: >>> >> >> No problems with gcc 4.4.0. Only a problem with gcc 4.1.2. >>> >> >> >>> >> >> Bill. >>> >> >> >>> >> >> 2009/5/28 Bill Hart <[email protected]>: >>> >> >>> It fails in iras as well, which is also ia64. >>> >> >>> >>> >> >>> I tried the optimisations one by one and none of them triggered it >>> >> >>> on their own. This is *nuts*. >>> >> >>> >>> >> >>> Bill. >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
