[PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[Richard Biener]

This obsoletes the 32bit hppa-hpux configurations which only support
STABS as debuginfo format.

As discussed, I'm going to push this (and a changes.html entry) when
it was included in a bootstrap/regtest cycle.

2021-09-20  Richard Biener  <rguenther@suse.de>

gcc/
	* config.gcc: Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*.

contrib/
	* config-list.mk: --enable-obsolete for hppa2.0-hpux10.1 and
	hppa2.0-hpux11.9.
---
 contrib/config-list.mk | 5 +++--
 gcc/config.gcc         | 2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index 28c0db7a26c..3e1d1321861 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -45,8 +45,9 @@ LIST = aarch64-elf aarch64-linux-gnu aarch64-rtems \
   epiphany-elf epiphany-elfOPT-with-stack-offset=16 fido-elf \
   fr30-elf frv-elf frv-linux ft32-elf h8300-elf hppa-linux-gnu \
   hppa-linux-gnuOPT-enable-sjlj-exceptions=yes hppa64-linux-gnu \
-  hppa2.0-hpux10.1 hppa64-hpux11.3 \
-  hppa64-hpux11.0OPT-enable-sjlj-exceptions=yes hppa2.0-hpux11.9 \
+  hppa2.0-hpux10.1OPT-enable-obsolete hppa64-hpux11.3 \
+  hppa64-hpux11.0OPT-enable-sjlj-exceptions=yes \
+  hppa2.0-hpux11.9OPT-enable-obsolete \
   i686-pc-linux-gnu i686-apple-darwin i686-apple-darwin9 i686-apple-darwin10 \
   i486-freebsd4 i686-freebsd6 i686-kfreebsd-gnu \
   i686-netbsdelf9 \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index c3a8b27f819..498c51e619d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -250,6 +250,8 @@ md_file=
 case ${target} in
   tile*-*-*				\
  | cr16-*-*				\
+ | hppa[12]*-*-hpux10*			\
+ | hppa[12]*-*-hpux11*			\
  )
     if test "x$enable_obsolete" != xyes; then
       echo "*** Configuration ${target} is obsolete." >&2
-- 
2.31.1

Re: [PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[Jeff Law]

On 9/20/2021 1:00 AM, Richard Biener wrote:
> This obsoletes the 32bit hppa-hpux configurations which only support
> STABS as debuginfo format.
>
> As discussed, I'm going to push this (and a changes.html entry) when
> it was included in a bootstrap/regtest cycle.
>
> 2021-09-20  Richard Biener  <rguenther@suse.de>
>
> gcc/
> 	* config.gcc: Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*.
>
> contrib/
> 	* config-list.mk: --enable-obsolete for hppa2.0-hpux10.1 and
> 	hppa2.0-hpux11.9.
Is this marking hppa2.0w-hp-hpux11 as obsolete?  That platform is using 
ELF & DWARF.

jeff

Re: [PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[Richard Biener]

On Mon, 20 Sep 2021, Jeff Law wrote:

> 
> 
> On 9/20/2021 1:00 AM, Richard Biener wrote:
> > This obsoletes the 32bit hppa-hpux configurations which only support
> > STABS as debuginfo format.
> >
> > As discussed, I'm going to push this (and a changes.html entry) when
> > it was included in a bootstrap/regtest cycle.
> >
> > 2021-09-20  Richard Biener  <rguenther@suse.de>
> >
> > gcc/
> >  * config.gcc: Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*.
> >
> > contrib/
> >  * config-list.mk: --enable-obsolete for hppa2.0-hpux10.1 and
> >  hppa2.0-hpux11.9.
> Is this marking hppa2.0w-hp-hpux11 as obsolete?  That platform is using ELF &
> DWARF.

If so then that's by mistake - I had the impression that all 32bit
hpux pa targets are STABS only, but that's from trying to decipher
config.gcc and the comments from you and David ... maybe the
matching pattern needs to be "split"?

Can you maybe take care of any adjustments necessary?  I've also
edited changes.html already.

Thanks,
Richard.

> jeff
> 
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[Richard Biener]

On Mon, 20 Sep 2021, Richard Biener wrote:

> On Mon, 20 Sep 2021, Jeff Law wrote:
> 
> > 
> > 
> > On 9/20/2021 1:00 AM, Richard Biener wrote:
> > > This obsoletes the 32bit hppa-hpux configurations which only support
> > > STABS as debuginfo format.
> > >
> > > As discussed, I'm going to push this (and a changes.html entry) when
> > > it was included in a bootstrap/regtest cycle.
> > >
> > > 2021-09-20  Richard Biener  <rguenther@suse.de>
> > >
> > > gcc/
> > >  * config.gcc: Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*.
> > >
> > > contrib/
> > >  * config-list.mk: --enable-obsolete for hppa2.0-hpux10.1 and
> > >  hppa2.0-hpux11.9.
> > Is this marking hppa2.0w-hp-hpux11 as obsolete?  That platform is using ELF &
> > DWARF.
> 
> If so then that's by mistake - I had the impression that all 32bit
> hpux pa targets are STABS only, but that's from trying to decipher
> config.gcc and the comments from you and David ... maybe the
> matching pattern needs to be "split"?

Btw, I don't see any elfos.h in the hppa[12]*-*-hpux11* case in config.gcc
and it contains a warning that the target doesn't support DWARF.  But yes,
that pattern matches hppa2.0-hpux11.9 and the hppa*64*-*-hpux11* pattern
doesn't - there's hppa64-hpux11.0 in config-list.mk that does though.

Richard.

> Can you maybe take care of any adjustments necessary?  I've also
> edited changes.html already.
> 
> Thanks,
> Richard.
> 
> > jeff
> > 
> > 
> > 
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[Jeff Law]

On 9/20/2021 10:46 AM, Richard Biener wrote:
> On Mon, 20 Sep 2021, Richard Biener wrote:
>
>> On Mon, 20 Sep 2021, Jeff Law wrote:
>>
>>>
>>> On 9/20/2021 1:00 AM, Richard Biener wrote:
>>>> This obsoletes the 32bit hppa-hpux configurations which only support
>>>> STABS as debuginfo format.
>>>>
>>>> As discussed, I'm going to push this (and a changes.html entry) when
>>>> it was included in a bootstrap/regtest cycle.
>>>>
>>>> 2021-09-20  Richard Biener  <rguenther@suse.de>
>>>>
>>>> gcc/
>>>>   * config.gcc: Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*.
>>>>
>>>> contrib/
>>>>   * config-list.mk: --enable-obsolete for hppa2.0-hpux10.1 and
>>>>   hppa2.0-hpux11.9.
>>> Is this marking hppa2.0w-hp-hpux11 as obsolete?  That platform is using ELF &
>>> DWARF.
>> If so then that's by mistake - I had the impression that all 32bit
>> hpux pa targets are STABS only, but that's from trying to decipher
>> config.gcc and the comments from you and David ... maybe the
>> matching pattern needs to be "split"?
> Btw, I don't see any elfos.h in the hppa[12]*-*-hpux11* case in config.gcc
> and it contains a warning that the target doesn't support DWARF.  But yes,
> that pattern matches hppa2.0-hpux11.9 and the hppa*64*-*-hpux11* pattern
> doesn't - there's hppa64-hpux11.0 in config-list.mk that does though.
Nuts, I think I steered you wrong.  I forgot that while HP used 
"hppa2.0w" to denote their 64 bit ELF platform, we used "hppa64" for the 
target name.

jeff

Re: [PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[John David Anglin]

On 2021-09-20 3:00 a.m., Richard Biener wrote:
> As discussed, I'm going to push this (and a changes.html entry) when
> it was included in a bootstrap/regtest cycle.
GCC 12 still builds on hppa2.0w-hp-hpux11.11 with --enable-obsolete:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-September/722961.html

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCH] Obsolete hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11*

[Richard Biener]

On Wed, 22 Sep 2021, John David Anglin wrote:

> On 2021-09-20 3:00 a.m., Richard Biener wrote:
> > As discussed, I'm going to push this (and a changes.html entry) when
> > it was included in a bootstrap/regtest cycle.
> GCC 12 still builds on hppa2.0w-hp-hpux11.11 with --enable-obsolete:
> https://gcc.gnu.org/pipermail/gcc-testresults/2021-September/722961.html

Yes, that's how it's supposed to be, but it will lose the ability to
emit (stabs) debug info when GCC 13 stage1 opens and we get along to
remove stabs support.  At that point maintaining the configuration
might cease to make sense.

Richard.