On Thu, Sep 23, 2010 at 11:44:45PM +0200, Gunnar Farneb?ck wrote: > On 09/23/10 20:52, Yann Dirson wrote: > >configure does report results for the compiler's target platform > >(which autostuff calls "host machine", it reserves "target machine" to > >talk about the target of a toolchain when we are building one - so the > >"canadian cross" setup is building on a "build machine" a compiler > >that will run on "host machine" to build binaries for "target > >machine" - now *that* is fishy ;) > > Ok, so then the world is basically sane. Is there any way of making > the target SIZEOF_LONG available to the native build?
It is already available, since for cross-compilation ./configure does not run for the build machine. > >>Here's an experiment you could try. After running configure on your > >>64-bit machine, change SIZEOF_LONG to 4, then do your cross-build and > >>see if fusekiN.c compiles better. > > > >It correctly reports SIZEOF_LONG as 4 when I cross-compîle, and 8 when > >I compile natively. But since my "build machine" printf's 64bit > >longs, the cross-compiler with 32bit longs issues truncation warnings. > > My idea is to cheat the native compilation to build with SIZEOF_LONG 4 > despite sizeof(long) being 8. But apparently it's also necessary to > first make this modification: > > diff --git a/engine/hash.c b/engine/hash.c > index 6ccf892..ee18352 100644 > --- a/engine/hash.c > +++ b/engine/hash.c > @@ -60,7 +60,7 @@ hash_rand(void) > int i; > Hashvalue h = 0; > > - for (i = 0; 32*i < (int) (CHAR_BIT*sizeof(Hashvalue)); i++) > + for (i = 0; 32*i < (int) (CHAR_BIT*SIZEOF_HASHVALUE); i++) > h |= (Hashvalue) gg_urand() << 32*i; > > return h; Ah, that may be what I missed. > After that uncompress_fuseki builds perfectly fine 32 bit fusekiN.c. > Unfortunately this won't work the other way round with forging > SIZEOF_LONG 8 when sizeof(long) is 4. (Not to speak of the horrors of > having different CHAR_BIT on host and target...) > > The primary problem is that, for efficiency reasons, uncompress_fuseki > generates hash values which are built into the final binary, so > uncompress_fuseki must agree on the hash value details with the board > library in the final build. This can be achieved by either: > 1. Building for and running uncompress_fuseki on the target platform. > 2. Having identical datatypes for Hashvalue on host and target. > 3. Giving uncompress_fuseki information about the size of Hashvalue on > the target platform. > > Alternative one is really the proper solution, although impractical in > practice. The second option is of course what your patch aims at but > it doesn't make proper use 64 bit registers when such are available, > there's no guarantee that uint32 exists (iirc), and it won't build > with c99 unaware compilers (I think). I really like the simplicity of > just using long. > > The third option requires that SIZEOF_LONG (and to be picky CHAR_BIT) > for the target is available to the native build and a bit more work to > make proper use of the knowledge. I'd prefer this approach if it's > feasible. Sounds sane. On a sidenode, rumors of full success of the testsuite on gta02 are slightly exagerated: it still has not finished (after nearly 36 hours), and there is finally (at least) this failure: ./regress.sh . nngs4.tst 480 unexpected FAIL: Correct 'R16', got 'Q17' _______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
