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

Previous Next

Full log

Message #17 received at 12754 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: John David Anglin <dave.anglin <at> bell.net>, Torbjorn Granlund <tg <at> gmplib.org>
Cc: 12754 <at> debbugs.gnu.org, John David Anglin <dave <at> hiauly1.hia.nrc.ca>
Subject: Re: bug#12754: factor.c selects 64 bit code from longlong.h on 32-bit
	hppa systems
Date: Mon, 29 Oct 2012 13:15:13 +0000

On 10/29/2012 12:16 PM, John David Anglin wrote:
> 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.

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 ?

thanks,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.