What are the outstanding issues? 2009/5/30 Jason Moxham <[email protected]>: > > 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 -~----------~----~----~----~------~----~------~--~---
