robert delius royar <xemacs(a)frinabulax.org> wrote:
The compile I posted yesterday is 4.1.4. The one from June 2005 was
earlier,
but I do not recall how earlier. I know I had to update when I updated
gnumeric.
Well, then, I don't understand those compiler warnings at all. They
appear to be claiming that mpz_get_ui() is somehow broken; i.e., that
the function can return without returning a value. If that is true,
then you are fundamentally screwed, because we use that function in
several places. In my version of the headers, the inline version of
that function is defined like this:
#if defined (__GMP_EXTERN_INLINE) || defined (__GMP_FORCE_mpz_get_ui)
#if ! defined (__GMP_FORCE_mpz_get_ui)
__GMP_EXTERN_INLINE
#endif
unsigned long
mpz_get_ui (mpz_srcptr __gmp_z) __GMP_NOTHROW
{
mp_ptr __gmp_p = __gmp_z->_mp_d;
mp_size_t __gmp_n = __gmp_z->_mp_size;
mp_limb_t __gmp_l = __gmp_p[0];
if (__GMP_ULONG_MAX <= GMP_NUMB_MASK)
return __gmp_l & (-(mp_limb_t) (__gmp_n != 0));
#if GMP_NAIL_BITS != 0 /* redundant #if, shuts up compiler warnings */
else /* happens for nails, but not if LONG_LONG_LIMB */
{ /* assume two limbs are enough to fill an ulong */
__gmp_n = __GMP_ABS (__gmp_n);
if (__gmp_n <= 1)
return __gmp_l & (-(mp_limb_t) (__gmp_n != 0));
else
return __gmp_l + (__gmp_p[1] << GMP_NUMB_BITS);
}
#endif
}
#endif
Hmmmmmm.... If __GMP_ULONG_MAX > GMP_NUMB_MASK and GMP_NAIL_BITS == 0,
that function CAN fall off the end. The comment implies that that can't
happen, but even so, could you compile and run this please and tell me
the results?
#include <stdio.h>
#include <gmp.h>
int main()
{
printf ("__GMP_ULONG_MAX == %lu\n", __GMP_ULONG_MAX);
printf ("GMP_NUMB_MASK == %lu\n", GMP_NUMB_MASK);
printf ("GMP_NAIL_BITS == %d\n", GMP_NAIL_BITS);
return 0;
}
Since no one else has reported this, I suspect it is powerPC
specific. It
occurs on both my G4 and G5 machines. I do not know if it is also OS X
specific or related to gcc4.0x. However, gcc4 does issue more warnings than
did gcc3.3 or gcc3.4 on my system, and it will not build some large well-known
projects that use old C++ code. But that is not related to the gmp failures.
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
It does *not* happen to me on a G4, gcc3.3 or gcc3.4, Mac OS X
10.3.9
"Panther". I now (as of yesterday) have a G4/10.4.6 machine, but (as
has happened at least four times before) Apple hosed the wifi drivers
badly and I've had a devil of a time getting the sources. (An upgrade
seems to have fixed the problem, in any case I now have XEmacs source,
but I don't have GMP yet, I don't think.)
gcc4 and/or Tiger is unending pain for those of us using DarwinPorts
on Panther; backward compatibility on some project seems to get broken
once or twice a week. I suspect that means big changes somewhere in
the underlying OS.
Okay, so this is a gcc4-specific problem then.
Incidentally, problems with GMP are not unique to gcc. I filed a bug
against ICC 8.0.066 on July 5, 2004, which has not been fixed up through
and including the current ICC 9.0.032. If you configure XEmacs to use
the union type and compile with any optimization whatsoever, ICC
miscompiles XEmacs. The first symptom of the miscompilation is that
adding small numbers together produces bignums, which leads to crashes
in the initialization code. This is ICC issue number 255632 for the
interested.
(To be fair, my initial experience with using ICC on XEmacs was that it
caused a segfault in mcpcom. I filed a bug report on that in April of
2004, and it was fixed in a release of ICC in late June. They were
quick to fix the segfault, even though they've been slow to fix the
optimizer bug.)
Regards,
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department
http://www.cs.usu.edu/~jerry/
Utah State University