This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Deprecate 32-bits HP-PA for GCC 4.8?


On Mon, May 7, 2012 at 7:42 PM, Jeff Law <law@redhat.com> wrote:
> On 05/07/2012 11:33 AM, Steven Bosscher wrote:
>>
>> Hello,
>>
>> GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
>> for targets to be deprecated. I have one I would like to put on the
>> list, so here's something to start a discussion with:
>>
>> Deprecate all support for 32-bits HP-PA. This includes HP-UX10, and
>> PA-7000 and older.
>
> No objections from me. ?PA1.x machines are ancient. ? However, before making
> the decision, I think making sure your facts are correct would be wise.

I always try to do so, but for something as ancient as PA1.x, it's not
so easy :-)

>> 3. The PA-7000 series only run HP-UX 10 or earlier, so support for
>> HP-7000 and older is pointless without HP-UX10 support.
>
> Does the PA linux port run on the older PA machines or did they restrict
> themselves to PA2.0 and newer? ?I certainly recall them working on 32bit
> ports at one time.

No, I think HP-PA linux also supports PA1.1. However, it's not clear
to me which linux distributions actually still support HP-PA at all.
Debian was probably the most wide-spread deployed hppa-linux, but
Debian dropped hppa support in 6.0 (squeeze). I've looked at
http://wiki.parisc-linux.org/Distributions to see if they have any
listed hardware restrictions, but they appear to be none.


>> 4. 32-bits HP-PA uses the SOM binary object format, i.e. it is a
>> non-ELF target (64-bits HP-PA is ELF).
>
> Well, there was a PA ELF 32 bit target, but I suspect that code has long
> since died.

I think 32-bits hppa-linux is ELF.


>> Removing support for anything older than PA-8000 results in a
>> considerable cleanup for the PA architecture: ~3300 lines out of
>> ~23000, estimated by cleaning all "!TARGET_64BIT" and "TARGET_PA_11"
>> patterns in pa.md and pa.c, and most of the cleanups to remove support
>> for SOM objects.
>
> IIRC TARGET_PA_11 was implicitly on when compiling 2.0 support. ?Again,
> worth checking since it may affect how much code you think you can clean up.

I didn't find that. These are all the TARGET_PA_11 tests I removed for
my experiment:

-  "TARGET_PA_11 && ! TARGET_SOFT_FLOAT"
-  "TARGET_PA_11 && ! TARGET_SOFT_FLOAT"
-  "TARGET_PA_11 && ! TARGET_SOFT_FLOAT"
-  "TARGET_PA_11 && ! TARGET_SOFT_FLOAT"
-  "TARGET_PA_11 && ! TARGET_SOFT_FLOAT"
-  "TARGET_PA_11 && ! TARGET_SOFT_FLOAT"
-  if (TARGET_PA_11 && !TARGET_DISABLE_FPREGS && !TARGET_SOFT_FLOAT)
-  "TARGET_PA_11 && ! TARGET_DISABLE_FPREGS && ! TARGET_SOFT_FLOAT"
-  "TARGET_PA_11 && ! TARGET_DISABLE_FPREGS && ! TARGET_SOFT_FLOAT &&
!TARGET_64BIT"
-  "TARGET_PA_11 && ! TARGET_DISABLE_FPREGS && ! TARGET_SOFT_FLOAT &&
TARGET_64BIT"
-  "TARGET_PA_11 && ! TARGET_SOFT_FLOAT
-  "TARGET_PA_11 && ! TARGET_SOFT_FLOAT
-  "TARGET_PA_11 && ! TARGET_SOFT_FLOAT
-  "TARGET_PA_11 && ! TARGET_SOFT_FLOAT

Ciao!
Steven


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]