Problems with GMP in latest Cygwin

[mwoehlke]

(TITTTL'd)

William Hart wrote:
> Firstly I was using Cygwin on a **64** bit Athlon,
> running on **32** bit Windows XP.
> 
> I'm not sure about what choices of bit length are made
> for long's under such circumstances, but one has to be
> very careful of the following:

Microsoft, in their "infinite wisdom", made long's 32-bit, even for 
64-bit targets (which is different from how the ENTIRE REST OF THE WORLD 
works - don't get me started, or at least TITTTL any continuation)... 
but, basically, if you are running a 32-bit OS on 64-bit hardware this 
should be no different than running the same 32-bit OS on 32-bit 
hardware. Of course I expect/hope that gcc, when it is ported to 64-bit 
Windows (soon, I think, since I hear binutils is ported) to make more 
reasonable decisions.

> 1) printf("%ld",longvar) expects a long
> 2) Using gmp_scanf and gmp_printf after instances of
> ordinary printf and scanf when the incorrect
> assumptions have been made about the length of a long
> may cause problems (note the compiler may not give an
> error or warning).
> 3) Replacing long's with u_int32_t's may further
> compound the problems: GMP expects a ui (in functions
> like mpz_mul_ui) to be 32 bits on a 32 bit machine and
> 64 bits on a 64 bit machine. But what does it expect
> on a 64 bit machine running in 32 bit mode? One must
> use a long, but this may cause issues elsewhere.

This I don't get; if GMP is doing anything that takes into account the 
hardware bits, independent of the OS bits, then IMO it is doing 
something wrong. At any rate, all SANE systems ought to be using the 
LPxx model; i.e. 'sizeof(long) == sizeof(void*)'. This has nothing to do 
with the hardware, since a 32-bit OS (or even a 32-bit program on a 
64-bit OS) still has 32-bit pointers and should therefore have 32-bit longs.

> Some combination of the above led me to write a
> program which compiled without warnings and which ran
> correctly on my 32 bit laptop, but which compiled
> correctly did not run correctly on my 64 bit Athlon
> running 32 bit Windows XP (under Cygwin). 

This I find VERY surprising. What was the program? The only possible 
explanation I can think of is that this program somehow was run in 
64-bit mode even though it is a 32-bit program (possibly because it 
intentionally alters itself depending on the hardware it is run on). I 
can think of no reason that identical assembly should not behave 
identically on different CPU's.

What you are suggesting has very serious ramifications.

> C is portable only if you are porting it to the same
> kind of machine, using the same operating system with
> the same kind of OS emulator!!

I thought you said you were doing this? 32-bit OS in both cases; 
emulation should be the same. If your 64-bit hardware can't run 32-bit 
code correctly then there is something very wrong with it. That, or 
there is something wrong with your code that 'fortuitously' works 
correctly on 32-bit hardware (some issue with sign extension, maybe).

-- 
Matthew
"Try to bring it back in one piece this time." -- Q (MI6)