Re: [gnugo-devel] Re: [PATCH 4/4] Autotools refresh.

[Yann Dirson]

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'