On Sunday 18 January 2009 18:59:46 Bill Hart wrote: > did it get to addmul or lshift yet? >
I'm not entirely sure , but these are the only functions that give errors eg make t-mul in the tests/mpz directory > I don't know what is different about them. They are done in a pretty > similar way to addmul_1 and submul_1. > > Bill. > > 2009/1/18 <ja...@njkfrudils.plus.com>: > > On Sunday 18 January 2009 18:45:35 Bill Hart wrote: > >> That's likely because by the time those reference functions are used, > >> the actual mpn functions referred to have already been tested. > >> > >> I don't think this can be the issue anyway, as everything works fine > >> on a 32 bit machine. > >> > >> The actual error I got was a red herring anyway. The actual > >> __gmp_cpuvec that we are after is defined in /mpn/x86_64/fat.c. > >> Somehow it isn't picking this file up when building libtests.la or > >> something in it. > >> > >> Bill. > > > > make[4]: `libtests.la' is up to date. > > /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -O2 -m64 -o > > t-bswap t-bswap.o libtests.la ../libgmp.la > > gcc -std=gnu99 -O2 -m64 -o .libs/t-bswap > > t-bswap.o ./.libs/libtests.a /root/mpir/mpir/mpir/trunk/.libs/libgmp.so > > ../.libs/libgmp.so /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined > > reference to `__gmpn_sub_n' > > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined reference to > > `__gmpn_cpuvec_init' > > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined reference to > > `__gmpn_cpuvec' > > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined reference to > > `__gmpn_add_n' > > collect2: ld returned 1 exit status > > > > Only add and sub have a problem , not addmul or lshift , whats different > > about them? > > > >> 2009/1/18 <ja...@njkfrudils.plus.com>: > >> > On Sunday 18 January 2009 17:26:54 Bill Hart wrote: > >> >> As a further data point make check works on cicero (which is a 32 bit > >> >> x86 Pentium 4) with --enable-fat. So I don't see why it shouldn't > >> >> work on a 64 bit machine. > >> >> > >> >> Bill. > >> > > >> > refmpn.c and refmpf.c have some referances to plain mpn_fn , change > >> > these to refmpn_fn > >> > > >> > this clears up some of the errors.... > >> > > >> >> 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: > >> >> > I've hacked up "support" for --enable-fat on x86_64. It's a bit > >> >> > hackish (though I think the 32 bit fat support was already > >> >> > hackish). > >> >> > > >> >> > At this moment however, make check will not build, with error: > >> >> > > >> >> > ./.libs/libtests.a(refmpn.o): In function `refmpn_mod_34lsub1': > >> >> > refmpn.c:(.text+0x1f3): undefined reference to `__gmpn_cpuvec' > >> >> > > >> >> > etc. Now refmpn.c #include gmp-impl.h which defines __gmpn_cpuvec > >> >> > on line 3783 *provided* WANT_FAT_BINARY is defined and set (see > >> >> > line 3753). The thing is, make requires that to be set in order to > >> >> > build a fat binary in the first place. Surely configure configures > >> >> > this the same for make and for make check. So I honestly don't know > >> >> > why make check fails. If anyone has any insight into this, please > >> >> > let me know. > >> >> > > >> >> > I'll now mention some of the more hackish aspects of getting > >> >> > --enable- fat to work on x86_64: > >> >> > > >> >> > * I removed the check for HAVE_HOST_CPU_FAMILY_x86 on line 3753 of > >> >> > gmp- impl.h. This was hackish. Obviously configure should not > >> >> > continue if fat binary is not supported on the host cpu. It > >> >> > shouldn't be left until this point to determine that. I did try to > >> >> > add a > >> >> > HAVE_HOST_CPU_FAMILY_x86_64 flag, but for some reason I couldn't > >> >> > get it to work. > >> >> > > >> >> > * I had to put a modified copy of yasm_mac.inc in /mpn and /mpn/ > >> >> > x86_64. Now it inserts suffices on function names when calling the > >> >> > macro GLOBAL_FUNC. Only when building a fat binary does it refer to > >> >> > these copies of yasm_mac.inc instead of the one in the root of the > >> >> > source tree, thus suffices will not be added for a normal build. > >> >> > > >> >> > * I had to copy /mpn/x86/fat/* into /mpn/x86_64/fat. But note that > >> >> > I have not defined any 64 bit family/model/stepping values in the > >> >> > fake CPUID tables in fat.c as of yet. This probably means that the > >> >> > fat binary which is build does nothing. But someone can add the > >> >> > relevant CPUID values if they feel so inspired. > >> >> > > >> >> > * Probably a fat binary build on x86_64 doesn't work on 64 bit > >> >> > Windows (I'm not talking about MSVC here, but something like > >> >> > Cygwin64 if and when it exists). because the filenames with > >> >> > suffices are longer than the usual 8.3 format. I don't know if this > >> >> > is a problem or not, but it might be. > >> >> > > >> >> > * Configure almost certainly can't find functions in multifunction > >> >> > yasm assembler files implemented with macros. It has no idea how to > >> >> > interpret the macro language of yasm. Thus functions probably won't > >> >> > be picked up from multifunction files. Whilst we use macros, we > >> >> > currently have separate files for each of the macro'd functions, so > >> >> > this is actually not a problem at present (it infers the function > >> >> > names from the filenames alone if they are not actually implemented > >> >> > as multifunction files). But it will break when we fix > >> >> > multifunction support. > >> >> > > >> >> > Lots of other hacking was required to get this far. But the above > >> >> > is the worst of it. I'll add it to a trac ticket for someone with > >> >> > more patience than myself to fix. > >> >> > > >> >> > Bill. > >> >> > > >> >> > On Jan 15, 1:25 am, "Bill Hart" <goodwillh...@googlemail.com> wrote: > >> >> >> 2009/1/15 Bill Hart <goodwillh...@googlemail.com>: > >> >> >> > The problem with --enable-fat on 64 bit systems is that it > >> >> >> > searches the 64 bit assembly directories for functions but sets > >> >> >> > the fat directories to the 32 bit x86 directories. This can > >> >> >> > easily be fixed. Lines 1457-1476 of configure.in need to be > >> >> >> > replicated for the following case statement which deals with 64 > >> >> >> > bit machines, but with the correct directories set. > >> >> >> > >> >> >> Actually this won't quite directly work. The reason is that in > >> >> >> order to determine which functions it should include in the fat > >> >> >> binary, it looks for PROLOGUE(mpn_fnname) in the assembly files. > >> >> >> We don't use that macro in the x86_64 assembly code (which is in > >> >> >> yasm format). > >> >> >> > >> >> >> We could fix this by modifying what it looks for appropriately on > >> >> >> x86_64. We should be looking for GLOBAL_FUNC mpn_fnname instead. > >> >> >> > >> >> >> Bill. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
