GNU bug report logs -
#12754
factor.c selects 64 bit code from longlong.h on 32-bit hppa systems
Previous Next
Full log
Message #32 received at 12754 <at> debbugs.gnu.org (full text, mbox):
On 10/30/2012 09:57 AM, Torbjorn Granlund wrote:
> John David Anglin <dave.anglin <at> bell.net> writes:
>
> The issue is _PA_RISC2_0 is not sufficient to distinguish between the
> 32-bit and 64-bit PA runtimes. While all PA 2.0 systems accept double
> word add instructions, it's possible for the context to get clobbered
> between the add and add,dc instructions in the asm on Linux and narrow
> HP-UX kernels. Not sure about BSD but it generally follows Linux.
>
> BSD supports PA 2.0 and has done so for the last decade.
All BSDs?
> The fix for this is long overdue and should be made to GCC; GCC should
> not support generation of code that will cause register clobbering
> issues.
>
> A compilation for the 2.0 ISA on GNU/Linux should be considered a cross
> compilation, and the target hppa-linux-gnu should be unsupported.
>
> I don't have any proposal for a temporary workaround in GNU coreutils.
> I have not implemented any workaround for GMP, and this seem to work OK.
> Very few people choose GNU/Linux on PA 2.0 systems for obvious reasons.
>
> GCC only generates double word instructions when compiling for the 64-
> bit runtime. For the 32-bit runtime, a long long has to be placed in
> two separate registers to meet the calling conventions. So, long
> longs are handled the same as for PA 1.X.
>
> GCC uses the 64-bit registers if PA 2.0 when it generates code for 2.0.
> The parameter transfer is the same for the 2.0n and 1.0 ABIs.
>
> The ABI=2.0w refers to a 64-bit HP-UX kernel.
>
> Huh?
>
> All 64-bit HP-UX kernels support both the 32 and 64-bit runtimes. It
> is possible to optimize certain operations in the 32-bit runtime using
> the 64-bit registers on but the benefit is not as great as one might
> expect because of the calling convention requirements.
>
> I expect a two-fold improvement for certain operations, and that's
> indeed what we get in GMP. But the speed issues seem secondary in this
> discusson. I regret the decison of the the Linux hppa hacker to not
> support 2.0, but I respect it. The correctness issues imposed by the
> incomatibility of the kernel and GCC is much more serious.
>
> An additional check such as the size of long is needed to distinguish
> the two cases.
>
> I believe that is incorrect, since long will stay 32 bits in the ABI
> denoted 2.0n.
You're saying this is incorrect because it needlessly penalizes
the gcc/bsd combination on 2.0n ?
If we could quantify which BSDs this was OK on, I might
construct an appropriate ifdef to enable this assembly.
Though at this stage I'm leaning towards disabling the code on 2.0n
along the lines of the following.
commit 10a094b7403810c9b2775361d9d477f4c9aeb02b
Author: Pádraig Brady <P <at> draigBrady.com>
Date: Tue Oct 30 02:02:05 2012 +0000
build: avoid build failure on some HPPA systems
* src/longlong.h: Restrict some HPPA assembly variants
to PA RISC V2.0. Note we also avoid this assembly for
ilp32 runtimes, since even though the assembly is
accepted there, it's not safe as the context can get
clobbered between the 'add' and 'add,dc'.
This fixes a compile failure with newer
HPPA systems with default gcc CPU options.
Reported by John David Anglin
diff --git a/THANKS.in b/THANKS.in
index 016a41e..6dc024b 100644
--- a/THANKS.in
+++ b/THANKS.in
@@ -303,6 +303,7 @@ Joey Hess joeyh <at> debian.org
Johan Boule bohan <at> bohan.dyndns.org
Johan Danielsson joda <at> pdc.kth.se
John Bley jbb6 <at> acpub.duke.edu
+John David Anglin dave.anglin <at> bell.net
John Gatewood Ham zappaman <at> alphabox.compsci.buu.ac.th
John Gotts jgotts <at> umich.edu
John Kendall kendall <at> capps.com
diff --git a/src/longlong.h b/src/longlong.h
index 8d71611..6a9ae48 100644
--- a/src/longlong.h
+++ b/src/longlong.h
@@ -679,7 +679,13 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype *, UWtype, UWtype,
/* These macros are for ABI=2.0w. In ABI=2.0n they can't be used, since GCC
(3.2) puts longlong into two adjacent 32-bit registers. Presumably this
is just a case of no direct support for 2.0n but treating it like 1.0. */
-#if defined (__hppa) && W_TYPE_SIZE == 64 && ! defined (_LONG_LONG_LIMB)
+#if defined (__hppa) && W_TYPE_SIZE == 64 && ! defined (_LONG_LONG_LIMB) \
+ && defined (_PA_RISC2_0) && (ULONGMAX_MAX == UINT64_MAX)
+/* Note the _PA_RISC2_0 above is to exclude this code from GCC with
+ default -march options which doesn't support these instructions.
+ Also the width check for 'long' is to avoid ilp32 runtimes where
+ GNU/Linux and narrow HP-UX kernels are known to have issues with
+ clobbering of context between the add and add,dc instructions. */
#define add_ssaaaa(sh, sl, ah, al, bh, bl) \
__asm__ ("add%I5 %5,%r4,%1\n\tadd,dc %r2,%r3,%0" \
: "=r" (sh), "=&r" (sl) \
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.