bug-gmp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch 4.1.3] Correctly handle zero operands with gcc on PA


From: Kevin Ryde
Subject: Re: [patch 4.1.3] Correctly handle zero operands with gcc on PA
Date: Tue, 25 May 2004 11:28:58 +1000
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux)

"John David Anglin" <address@hidden> writes:
>
> I also note ...

Separate messages for separate matters, it's too confusing otherwise.

> that there are some inconsistencies in how gmp-4.1.3
> treats hppa*-*-hpux* configure options relative to other packages.
> See configfsf.guess to see how these options are currently being set.

We don't pay too much attention to the ABI or other extra information
worked into the cpu type by config.guess, we prefer to read the cpu
type as indicating the cpu type, and have a separate ABI=xx to drive
the ABI.  This becomes significant when recognising various exact cpu
types, something not presently done for hppa.

> Gmp treats hppa2.0w as indicating
> that the compiler supports 64-bit longs and PA 2.0 features.  This
> is wrong.

You have to say what you do, what gmp does, and what you think it
should do.

But what I can say is we treat hppa2.0w and hppa2.0 as the same thing,
a pa 2.0 cpu, and then we worry what ABIs the system actually
supports.  Having hppa2.0n default to ABI=2.0n is a nod to what we
understand as the intention of that versus hppa2.0w, ie. to ask for
the 2.0n ABI.  Or that's the theory.

> There are only two defined runtimes, irrespective of the PA architecture
> (aside from the minor differences in the 32-bit runtime between hpux
> 10 and 11).  It is possible to use some of the PA 2.0 64-bit features
> under the 32-bit runtime when running a wide kernel as it saves the
> full 64-bit context state.  GCC doesn't do this as 64-bit register
> values are not preserved across function calls.  You can currently fudge
> this by configuring gmp with hppa2.0n.

We interpret 2.0n as permission to use 64-bit regs etc in the asm
code, but with the 32-bit calling conventions.

> However, this isn't portable, and
> you need '-mpa-risc-2-0' set in CFLAGS as otherwise gas will object to
> the use of PA 2.0 features.

I'm not sure we've ever had a gas to try 2.0n.  We give .level
directives in the asm code though.

What gcc generates is a matter for it, though we do try to exercise
enough in the configure tests to reject outright faulty setups.

> To get portable 32-bit code on a PA 2.0 system,
> you need to explicitly configure gmp using '--host=hppa1.1-hp-hpux11.11
> --build=hppa1.1-hp-hpux11.11'.

You should get that effect from ABI=1.0, see the manual for a full
description.

> then possibly this
> should be controlled by a separate "--with" option.

Well not --with, which is not for modes or options.  It'd be either
--enable, or a variable like ABI that we now use.

-- 
All followups to address@hidden please.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]