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

[John David Anglin]

On 28-Oct-12, at 10:26 PM, Pádraig Brady wrote:

> On 10/28/2012 07:46 PM, John David Anglin wrote:
> > When USE_LONGLONG_H is defined, factor.c unilaterally defines  
> > W_TYPE_SIZE
> > to 64.  This selects the wrong code from longlong.h on 32-bit hppa  
> > systems
> > causing an assembly failure.
> >
> > Attached is a hack which should work on most but probably not all  
> > systems.
>
> This is closely related to the general solution I proposed
> for http://bugs.gnu.org/12753#8
> I.E. making the size of uintmax_t available to the preprocessor.
> A particular size doesn't matter according to:
> http://lists.gnu.org/archive/html/bug-coreutils/2012-09/msg00111.html
>
> So I'll do something like the following.
>
> thanks,
> Pádraig.
>
> diff --git a/src/factor.c b/src/factor.c
> index 4c2af98..1b1b37f 100644
> --- a/src/factor.c
> +++ b/src/factor.c
> @@ -124,7 +124,16 @@
> #if USE_LONGLONG_H
>
> /* Make definitions for longlong.h to make it do what it can do for  
> us */
> -# define W_TYPE_SIZE 64          /* bitcount for uintmax_t */
> +
> +/* bitcount for uintmax_t */
> +#if UINTMAX_MAX == UINT32_MAX
> +# define W_TYPE_SIZE 32

This won't work for 32-bit hppa systems because the uintmax_t type is
64 bits (long long) and the "word" size is 32 bits.  The distinction  
between
the 64-bit and 32-bit runtimes is the size of long.  I think the most  
common
cases are:

@item ilp32
Target has 32-bit @code{int}, @code{long}, and pointers.

@item lp64
Target has 32-bit @code{int}, 64-bit @code{long} and pointers.

@item llp64
Target has 32-bit @code{int} and @code{long}, 64-bit @code{long long}
and pointers.

Dave
--
John David Anglin       address@hidden