bug#12754: factor.c selects 64 bit code from longlong.h on 32-bit hppa systems

[Torbjorn Granlund]

Pádraig Brady <address@hidden> writes:

  Sure, but from the message linked above it seems that
  the size of uintmax_t is significant here rather than the "word" size.
  
  Torbjorn should W_TYPE_SIZE match the "word" size or uintmax_t ?
  
We're setting things up for arithmetic on uintmax_t (one or two of
these).

W_TYPE_SIZE is then used to ask longlong.h to define a couple of macros
(documented in the beginning of that file) which provide arithmetic
based on that size.  Then longlong.h will do it in assembly or in C.

W_TYPE_SIZE must thus be the size of uintmax_t.

The problems we've seen are related to this slightly backward use of
longlong in factor.c.  In GMP (the main home of longlong.h) we figure
out the real word size, and then define W_TYPE_SIZE to that.

The trick around this is to find better API specific predefs to test in
longlong.h, juist like Pádraig did for sparc.  If no such predefs exist,
we can either set something up via configure to define some cpp symbol,
or we need to disable the problematic assembly.  This will hurt
performance, but will not affect program behaviour.

-- 
Torbjörn