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

[Jerry James]

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;
}

> 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,
-- 
Jerry James, Assistant Professor        james at xemacs.org
Computer Science Department             http://www.cs.usu.edu/~jerry/
Utah State University