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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12754 in the body.
You can then email your comments to 12754 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: John David Anglin <dave <at> hiauly1.hia.nrc.ca>
To: bug-coreutils <at> gnu.org
Cc: John David Anglin <dave <at> hiauly1.hia.nrc.ca>
Subject: factor.c selects 64 bit code from longlong.h on 32-bit hppa systems
Date: Sun, 28 Oct 2012 15:46:44 -0400

[Message part 1 (text/plain, inline)]

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.

Dave
-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

[factor.c.d (text/plain, attachment)]

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

From: Dave Anglin <dave.anglin <at> bell.net>
To: <12754 <at> debbugs.gnu.org>
Subject: Re: bug#12754: Acknowledgement (factor.c selects 64 bit code from
	longlong.h on 32-bit hppa systems)
Date: Sun, 28 Oct 2012 17:55:55 -0400

Patch is wrong.  Maybe it is better to define NO_ASM.

Message #11 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> nrc-cnrc.gc.ca>
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 02:26:58 +0000

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
+#elif UINTMAX_MAX == UINT64_MAX
+# define W_TYPE_SIZE 64
+#elif UINTMAX_MAX == UINT128_MAX
+# define W_TYPE_SIZE 128
+#endif
+
 # define UWtype  uintmax_t
 # define UHWtype unsigned long int
 # undef UDWtype

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

From: John David Anglin <dave.anglin <at> bell.net>
To: Pádraig Brady <P <at> draigBrady.com>
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 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	dave.anglin <at> bell.net

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.

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

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

Pádraig Brady <P <at> draigBrady.com> writes:

  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 ?
  
We're setting things up for arithmetic on uintmax_t (one or two of
these).

W_TYPE_SIZE is then used to ask longlong.h to define a couple of macros
(documented in the beginning of that file) which provide arithmetic
based on that size.  Then longlong.h will do it in assembly or in C.

W_TYPE_SIZE must thus be the size of uintmax_t.

The problems we've seen are related to this slightly backward use of
longlong in factor.c.  In GMP (the main home of longlong.h) we figure
out the real word size, and then define W_TYPE_SIZE to that.

The trick around this is to find better API specific predefs to test in
longlong.h, juist like Pádraig did for sparc.  If no such predefs exist,
we can either set something up via configure to define some cpp symbol,
or we need to disable the problematic assembly.  This will hurt
performance, but will not affect program behaviour.

-- 
Torbjörn

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

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

On 10/29/2012 01:27 PM, Torbjorn Granlund wrote:
> Pádraig Brady <P <at> draigBrady.com> writes:
>
>    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 ?
>
> We're setting things up for arithmetic on uintmax_t (one or two of
> these).
>
> W_TYPE_SIZE is then used to ask longlong.h to define a couple of macros
> (documented in the beginning of that file) which provide arithmetic
> based on that size.  Then longlong.h will do it in assembly or in C.
>
> W_TYPE_SIZE must thus be the size of uintmax_t.
>
> The problems we've seen are related to this slightly backward use of
> longlong in factor.c.  In GMP (the main home of longlong.h) we figure
> out the real word size, and then define W_TYPE_SIZE to that.
>
> The trick around this is to find better API specific predefs to test in
> longlong.h, juist like Pádraig did for sparc.  If no such predefs exist,
> we can either set something up via configure to define some cpp symbol,
> or we need to disable the problematic assembly.  This will hurt
> performance, but will not affect program behaviour.

OK thanks for the info.
I tested with gcc-4.3.2 on 9000/785/J6000 and similarly
to the sparc case, the default compile failed because
gcc defaulted to a more compatible arch.

So using the same technique to get something for
the preprocessor to key on...

$ for cpu in 1.0 1.1 2.0; do
  echo "--------- $cpu --------"
  cpp -march=$cpu -dM /dev/null |
  grep -i pa_
done
--------- 1.0 --------
#define _PA_RISC1_0 1
#define __hppa__ 1
--------- 1.1 --------
#define _PA_RISC1_1 1
#define __hppa__ 1
--------- 2.0 --------
#define _PA_RISC2_0 1
#define __hppa__ 1

Since 2.0 is the only arch that supports the 64 bit hppa code in longlong.h,
the following enables the code to compile by default.

diff --git a/src/longlong.h b/src/longlong.h
index 8d71611..8b01696 100644
--- a/src/longlong.h
+++ b/src/longlong.h
@@ -679,7 +679,7 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype *, 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) && defined (_PA_RISC2_0) && W_TYPE_SIZE == 64 && ! defined (_LONG_LONG_LIMB)
 #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)                                      \

Note even though I've not encountered a system yet where uintmax_t != 64 bit,
I'll add the guards around "#define W_TYPE_SIZE", previously mentioned in
this thread, in a separate patch.

cheers,
Pádraig.

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

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

On 29-Oct-12, at 9:59 PM, Pádraig Brady wrote:

> --------- 2.0 --------
> #define _PA_RISC2_0 1
> #define __hppa__ 1
>
> Since 2.0 is the only arch that supports the 64 bit hppa code in  
> longlong.h,
> the following enables the code to compile by default.

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.

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.

The ABI=2.0w refers to a 64-bit HP-UX kernel.  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.

An additional check such as the size of long is needed to distinguish  
the two cases.

Dave
--
John David Anglin	dave.anglin <at> bell.net

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

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

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.

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.

-- 
Torbjörn

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

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

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)                                      \

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

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

On 10/30/2012 6:21 AM, Pádraig Brady wrote:
> -#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.  */
This #if looks good to me.

Note HP compilers also define _PA_RISC2_0 when generating PA 2.0
assembly code.

Thanks,
Dave

-- 
John David Anglin    dave.anglin <at> bell.net

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

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

On 10/30/2012 5:57 AM, Torbjorn Granlund wrote:
> 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.
As far as I'm aware, GCC does not generate code that will cause register 
clobbering
issues.  What applications do in asms is beyond the control of GCC.
> 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.
Incorrect.  GCC supports generate generation of PA 2.0 code for both 32 
and 64-bit
environments.
>    
>    The ABI=2.0w refers to a 64-bit HP-UX kernel.
>
> Huh?
I assume you are thinking about the ABI parameter used by GMP.

Look at config.guess to see how it works.  When it returns "hppa2.0w" 
for the target
machine, the target has a 64-bit wide kernel and the compiler is 
generating code for the
32-bit runtime.  It returns "hppa64" when the target is generating code 
for the 64-bit ELF
runtime.  In terms of assembly code, this is the difference between 
".level 2.0" and
".level 2.0w".

>
>    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.
>
>    
You are essentially arguing for a second 32-bit runtime with 64-bit 
registers, calling
conventions, probably based on ELF.  I know there were discussions in HP 
about this
but it was never fully defined.

There is no incompatibility between GCC and the kernel as far as I 
know.  Specifically,
what are you talking about?

The initial decisions regarding the runtime architecture for Linux were 
taken by HP
and it contractors.  Yes, it would have been nice if support was there 
for a full 64-bit
context when the kernel was running on a PA 2.0 machine.  Changing it 
now will
break userspace exception support in a variety of applications.

There are certainly some opportunities to improve optimizations for 
HP-UX specific
code.  In the present case, this can be tested for using the "__hpux__" 
preprocessor
define.

Dave

-- 
John David Anglin    dave.anglin <at> bell.net

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

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

No disrespect intended, but I am unable to continue the discussion about
HP and Linux.

-- 
Torbjörn

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

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

On 10/30/2012 01:59 AM, Pádraig Brady wrote:
> Since 2.0 is the only arch that supports the 64 bit hppa code in longlong.h,
> the following enables the code to compile by default.
>
> diff --git a/src/longlong.h b/src/longlong.h
> index 8d71611..8b01696 100644
> --- a/src/longlong.h
> +++ b/src/longlong.h
> @@ -679,7 +679,7 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype *, 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) && defined (_PA_RISC2_0) && W_TYPE_SIZE == 64 && ! defined (_LONG_LONG_LIMB)
>   #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)                                      \
>
> Note even though I've not encountered a system yet where uintmax_t != 64 bit,
> I'll add the guards around "#define W_TYPE_SIZE", previously mentioned in
> this thread, in a separate patch.

I've now pushed the patch set discussed in this thread,
so I'm marking this bug as done.

cheers,
Pádraig.

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

From: John David Anglin <dave.anglin <at> bell.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 12754-done <at> debbugs.gnu.org, John David Anglin <dave <at> hiauly1.hia.nrc.ca>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#12754: factor.c selects 64 bit code from longlong.h on 32-bit
	hppa systems
Date: Sat, 3 Nov 2012 21:25:04 -0400

On 3-Nov-12, at 8:54 PM, Pádraig Brady wrote:

> I've now pushed the patch set discussed in this thread,
> so I'm marking this bug as done.

Hopefully, it's the one with the _LP64 check.

Regards,
Dave
--
John David Anglin	dave.anglin <at> bell.net

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

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

On 11/04/2012 01:25 AM, John David Anglin wrote:
> On 3-Nov-12, at 8:54 PM, Pádraig Brady wrote:
>
>> I've now pushed the patch set discussed in this thread,
>> so I'm marking this bug as done.
>
> Hopefully, it's the one with the _LP64 check.

Yes:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=da1329e7

Also this related one already mentioned:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=6108baa4

thanks,
Pádraig.

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

From: John David Anglin <dave.anglin <at> bell.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 12754-done <at> debbugs.gnu.org, John David Anglin <dave <at> hiauly1.hia.nrc.ca>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#12754: factor.c selects 64 bit code from longlong.h on 32-bit
	hppa systems
Date: Sat, 3 Nov 2012 22:00:41 -0400

On 3-Nov-12, at 9:44 PM, Pádraig Brady wrote:

> Also this related one already mentioned:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=6108baa4


This one seems to have lost

+#include <inttypes.h>

from the original patch to make-prime-list.c.  I think this is needed  
to define
PRIxMAX.

Regards,
Dave
--
John David Anglin	dave.anglin <at> bell.net

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

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

On 11/04/2012 02:00 AM, John David Anglin wrote:
>
> On 3-Nov-12, at 9:44 PM, Pádraig Brady wrote:
>
>> Also this related one already mentioned:
>> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=6108baa4
>
>
> This one seems to have lost
>
> +#include <inttypes.h>
>
> from the original patch to make-prime-list.c.  I think this is needed to define
> PRIxMAX.

So the patches were adjusted slightly and since they spanned both
this issue and issue 12753 I didn't post them in full again
to a particular issue, to avoid confusion, which I've obivously failed in.
Forry about that, I won't do that again :)

Anyway the patch referenced above didn't actually introduce PRIxMAX,
that was done in this patch from issue 12753
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=5e940180

thanks for all the double checking,
Pádraig.

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

From: John David Anglin <dave.anglin <at> bell.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 12754-done <at> debbugs.gnu.org, John David Anglin <dave <at> hiauly1.hia.nrc.ca>,
	Torbjorn Granlund <tg <at> gmplib.org>
Subject: Re: bug#12754: factor.c selects 64 bit code from longlong.h on 32-bit
	hppa systems
Date: Sat, 3 Nov 2012 22:22:43 -0400

On 3-Nov-12, at 10:11 PM, Pádraig Brady wrote:

> Forry about that, I won't do that again :)

No problem.

The GCC commit system generates an entry in bugzilla provided
one correctly tags the commit.  Makes it easy to track fixes for a PR.

Regards,
Dave
--
John David Anglin	dave.anglin <at> bell.net

Previous Next

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