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

From: John David Anglin <[email-masked]>
Date: Mon, 29 Oct 2012 08:16:17 -0400

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	[email-masked]