On Saturday 30 May 2009 11:55:53 Bill Hart wrote: > What are the outstanding issues?
two were just my crappy script :) fulvia , is probably same as above , I goner look at it now and the mark/sparc wierd issue that make check fails only sometimes.Its probably another path/script issue , as the sparcs pass the other 12 builds OK cuda1 is back up , I just cant log in Jason > > 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 -~----------~----~----~----~------~----~------~--~---
