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

[Torbjorn Granlund]

John David Anglin <address@hidden> 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