Bignum support still broken on powerpc (ping: Jerry James)

robert delius royar xemacs at frinabulax.org
Thu Apr 6 12:44:56 EDT 2006


Thu, 6 Apr 2006 (10:08 -0600 UTC) Jerry James wrote:

> robert delius royar <xemacs at 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;
> }

% gcc -o /tmp/gmptest -I/opt/local/include -L/opt/local/lib ~/scratch/gmptest.c
% /tmp/gmptest
__GMP_ULONG_MAX == 4294967295
GMP_NUMB_MASK == 4294967295
GMP_NAIL_BITS == 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 at 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,
>

-- 
Dr. Robert Delius Royar                   Associate Professor of English
Morehead State University                             Morehead, Kentucky
                                    Making meaning one message at a time.
   Too many OB-GYNs aren't able to practice their love with women all across
   this country.
        George Bush comments on why doctors should be exempt from litigation
   12:41 up 2 days, 3:02, 1 user, load averages: 0.07 0.06 0.03




More information about the XEmacs-Beta mailing list