John David Anglin <[email protected]> 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
