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

Previous Next

Package: coreutils;

Reported by: John David Anglin <dave.anglin <at> nrc-cnrc.gc.ca>

Date: Sun, 28 Oct 2012 19:50:01 UTC

Severity: normal

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

Bug is archived. No further changes may be made.

Full log


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





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.