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.