GNU bug report logs -
#12754
factor.c selects 64 bit code from longlong.h on 32-bit hppa systems
Previous Next
Full log
Message #14 received at 12754 <at> debbugs.gnu.org (full text, mbox):
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 dave.anglin <at> bell.net
This bug report was last modified 12 years and 205 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.