GMP patch: MinGW/win64 port
Wesley W. Terpstra
wesley at terpstra.ca
Tue Mar 4 20:20:00 CET 2008
On Tue, 2008-04-03 at 16:23 +0100, Torbjorn Granlund wrote:
> long long x = 34324;
> printf("blah: %"PRIdMAX"\n", (uintmax_t)x);
> AFAIK, this should be portable to all systems (including mingw/win64).
> I strongly doubt it to be portable in the sense we need for GMP.
That is C99. If it doesn't work, file a bug against the compiler and/or
add an autoconf workaround.
> > I am troubled by your tests/amd64check.c change, since it
> > unconditionally changes the constants to 'long long'. Not all
> > compilers might have that type. Could you please try using the
> > CNST_LIMB mechanism instead?
> amd64check is only for amd64. What amd64 compiler does not have long
> long? AFAIK, none. I doubt such a compiler will ever exist.
> Again, I disagree, there might be iso c90 compilers for this target.
> Being conservative about this sort of things is better.
That's pretty unlikely as amd64 is very new and c90 is very old. A
compiler targetting amd64 would need a 64 bit integer type. I suppose
it's possible that long=64 and int=32 on some yet-to-be-ported and
not-to-be-upgraded c90 compiler targetting amd64. If you are concerned
about this possibility, feel free to use intmax_t, or, as you worry C99
is unsupported, add an autoconf rule to setup a typedef for it.
While being conservative is good, working is better. long is wrong. Your
only options are 'long long' or a typedef (like intmax_t).
At any rate, I don't have much interest in a portability discussion
about how/if my patch is applied for gmp to work on mingw/win64. It
already works enough for MLton, which is all I needed.
More information about the gmp-bugs