It would of been faster to write a new itanium asm version of MPN_ZERO :) I nearly finished testing on skynet eno,menas,mark,cicero,sage,varro,mark2,cleo,iras,cato,fulvia and box1,2,3,modular.jmu I can't login to cuda1 at the moment , is it back up yet?
I've tested all the installed gcc's,cc's , with and without fat(where appropriate) for 1)no options 2)everything 3)everything+debug 4)max debug I've excluded known broken stuff itanium gcc-4.1.2 broken modular.jmu g++-3.4 broken Just four outstanding issues on mark,mark2,fulvia I used a script mpirtest in svn branches/test_stuff and the skynet_bash_profile to set paths Jason On Saturday 30 May 2009 11:15:11 Bill Hart wrote: > 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 -~----------~----~----~----~------~----~------~--~---
