I have to go out this evening , but I'll start "try" tests for x86_64 on all the relevant machines.
On Saturday 30 May 2009 12:09:38 Jason Moxham wrote: > 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 -~----------~----~----~----~------~----~------~--~---
