This is the mail archive of the
cygwin-talk
mailing list for the cygwin project.
Re: Problems with GMP in latest Cygwin
- From: mwoehlke <mwoehlke at tibco dot com>
- To: cygwin-talk at cygwin dot com
- Cc: hart_wb at yahoo dot com
- Date: Mon, 09 Oct 2006 11:08:16 -0500
- Subject: Re: Problems with GMP in latest Cygwin
- Original-to: your CPU am borken
- References: <20060928141602.70509.qmail@web82305.mail.mud.yahoo.com> <20061007202454.67767.qmail@web82304.mail.mud.yahoo.com>
- Reply-to: The Cygwin-Talk Maiming List <cygwin-talk at cygwin dot com>
(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)