[gnugo-devel] Re: [PATCH] [WIP] use uint32_t for Hashvalue if available.

[Yann Dirson]

On Wed, Sep 22, 2010 at 10:34:26PM +0200, Yann Dirson wrote:
> This makes it much more probable to cross-compile without integer-size
> issues.
> 
> Only uint32_t since for some reason cross-compiling from 64bit to 32bit
> causes problems when using uint64_t.
> ---
>  configure     |   85 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  configure.in  |    6 ++++
>  engine/hash.h |   22 +++++++++++++-
>  3 files changed, 111 insertions(+), 2 deletions(-)
> 
> Note: this is only a PoC patch, which allows to get rid of "integer
> constant is too large for 'long' type" warning compiling fuseki*.c.
> The fact it does not work with uint64_t is suspect.
> 
> I'm waiting for the regression tests to complete without this patch
> before testing that one - but even if it improves the mark, that would
> not say the patch is 100% correct.

Well, on the Freerunner (gta02) the tests all run fine without this
patch.  On afterthought that seems natural if the hash algo is
correct: we should be able to select any 64-bit mask to 64-bit hashes
from the generated 128-bit ones.

So what are we left with ?

- the case of cross-compiling on a build machine that has a smaller
  wordsize than the host machine: quite uncommon, usually in this case
  people would mostly cross-compile a base system with toolchain, and
  then compile games natively.  We can however probably detect the
  case and bomb out.

- the case I have of cross-compiling for a smaller-wordsize platform,
  where the only problem after all is the warnings.  We should be able
  to silence them (and, more importantly) make the result more
  explicit) by inserting explicit truncating casts in the generated
  code, shouldn't we ?

Best regards,
-- 
Yann