It's target deprecation season again!

It's target deprecation season again!

[Zack Weinberg]

It's time to decide which targets should be deprecated for the 3.3
release and removed in 3.4.

vax-*-vms* has already gone, and there was much rejoicing.

These targets were proposed for deprecation in 3.1 but preserved
because there might still be interest:

  mips-sni-sysv4
  m88k-*-*
  ns32k-*-*
  romp-*-*

Of these, only ns32k has seen any activity other than global cleanups
since the 3.1 release.  So I propose to remove ns32k-*-* from the
deprecation list, and pull the plug on the others.

There was some discussion of dropping i960-*-*; I didn't see it come
to a conclusion.

The i370 and s390 targets are for the same architecture.  They are not
entirely redundant; each supports operating environments that the
other doesn't.  However, the s390 target is actively maintained, the
i370 isn't, and HOST_EBCDIC doesn't really work.  I would like to
suggest, therefore, that we drop (a) the i370, and (b) any pretense of
supporting EBCDIC as the primary character encoding for the host.  (It
is much, much easier to support it in the target.)

It doesn't appear to me that we have any other dead architectures.
The vax and the pdp11 are arguable, but they do have active
maintainers.

Moving on to specific targets that might be worth dropping, here is my
list.  Some of these may well be live; I'm pretty ruthless.  Some of
these canonical names are not actually used as such, they're just
evocative (foo-*-netbsd*aout*, for instance, actually manifests as one
stanza for foo-*-netbsdelf* followed by another for foo-*-netbsd* -
it's my intention to propose deprecation of the a.out target only).

zw

alpha*-*-unicosmk*
alpha*-*-interix*   # all - underlying OS is alpha-win32, which is dead
alpha*-*-linux*libc1*
alpha*-dec-osf4*

arm*-*-coff*
arm*-*-aout*
arm*-*-aof*
arm*-*-conix*
arm*-*-oabi
arm*-*-netbsd*aout*  # submit your elf port already!
strongarm-*-coff*

cris-*-aout

hppa1.0-*-osf*
hppa1.0-*-bsd*
hppa1.[01]-*-hpux[789]*
hppa*-*-hiux*
hppa*-*-lites*
hppa*-*-mpeix*

i?86-ncr-*
i?86-sequent-*
i?86-moss-*
i?86-*-netware
i?86-*-freebsd2*
i?86-*-freebsd*aout*
i?86-*-netbsd*aout*
i?86-*-coff*
i?86-*-linux*aout*
i?86-*-linux*libc1
i?86-*-moss*
i?86-*-lynxos*
i?86-*-sysv3*
i?86-*-vsta
i?86-*-interix # not interix3

m68000-hp-bsd*
m68000-hp-hpux*
m68000-sun-sunos*
m68000-att-sysv*
m68k-atari-sysv*
m68k-motorola-sysv*
m68k-ncr-sysv*
m68k-plexus-sysv*
m68k-tti-*
m68k-crds-unos*
m68k-cbm-sysv*
m68k-ccur-rtu*
m68k-hp-bsd*
m68k-hp-hpux*
m68k-sun-mach*
m68k-sun-sunos*
m68k-*-linux*aout*
m68k-*-linux*libc1
m68k-*-psos*

mips-sgi-irix5*
mips*-*-ecoff*

ns32k-*-netbsd*aout*  # submit your elf port already!

powerpc*-*-sysv*  # the generic one only
powerpc*-*-linux*libc1
rs6000-ibm-aix[123]*
rs6000-ibm-aix4*  # maybe
rs6000-bull-bosx
rs6000-*-mach*
rs6000-*-lynxos*

sh-*-*coff*

sparc-tti-*
sparc-*-aout*
sparc-*-netbsd*aout*
sparc-*-bsd*
sparc-*-chorusos*
sparc-*-linux*aout*
sparc-*-linux*libc1*
sparc-*-lynxos*
sparc-hal-solaris2*
sparc-*-sunos[34]*
sparclet-*-aout*
sparclite-*-coff*
sparclite-*-aout*
sparc86x-*-aout*

vax-*-bsd*
vax-*-sysv*
vax-*-netbsd*aout*
vax-*-ultrix*

Re: It's target deprecation season again!

[Joseph S. Myers]

On Fri, 18 Oct 2002, Zack Weinberg wrote:

> i?86-*-linux*libc1

There are bug reports from people trying to use this (indicating it has
been bitrotten since 3.0).  This can be interpreted as the presence of
(attempted) users meaning it should be fixed, or the bitrottenness since
3.0 meaning it should just be removed.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: It's target deprecation season again!

[Jason R Thorpe]

On Fri, Oct 18, 2002 at 04:05:08PM -0700, Zack Weinberg wrote:

 > arm*-*-netbsd*aout*  # submit your elf port already!

Krister Walfridsson still occasionally sends testsuite results for this
target, and the last NetBSD ARM a.out release (1.5 branch) is not EOL'd
yet, so please don't put this on the list.

Regarding the ELF port ... "I'm working on it."  But GCC has to support
the ABI that NetBSD uses, and folding in all those changes is taking
longer than I'd expected (there's only a few left, thankfully...)

 > ns32k-*-netbsd*aout*  # submit your elf port already!

Please don't put this one on the list.  In order to submit the ELF port,
we need to sit down and define the ELF ABI for ns32k.  We should be able
to essentially just copy elf32-vax and tweak it, but this all takes time.
In the mean time, the a.out target works, and is in-use by at least 2 PC532
owners (3, as soon as I can get mine back in a case :-)

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: It's target deprecation season again!

[Mike Stump]

On Friday, October 18, 2002, at 04:05 PM, Zack Weinberg wrote:
> Of these, only ns32k has seen any activity other than global cleanups
> since the 3.1 release.  So I propose to remove ns32k-*-* from the
> deprecation list, and pull the plug on the others.

Sounds good.

> There was some discussion of dropping i960-*-*; I didn't see it come
> to a conclusion.

The conclusion is that it should stay.  We should have a timeout list, 
and place i960 on it so that we can renominate it in 2-4 years time.

Re: It's target deprecation season again!

[H. J. Lu]

On Sat, Oct 19, 2002 at 12:22:32AM +0100, Joseph S. Myers wrote:
> On Fri, 18 Oct 2002, Zack Weinberg wrote:
> 
> > i?86-*-linux*libc1
> 
> There are bug reports from people trying to use this (indicating it has
> been bitrotten since 3.0).  This can be interpreted as the presence of
> (attempted) users meaning it should be fixed, or the bitrottenness since
> 3.0 meaning it should just be removed.
> 

As the maintainer of libc1, I have to say it has served its purpose.
Now it should be RIP.


H.J.

Re: It's target deprecation season again!

[Zack Weinberg]

On Fri, Oct 18, 2002 at 04:26:20PM -0700, Jason R Thorpe wrote:
> On Fri, Oct 18, 2002 at 04:05:08PM -0700, Zack Weinberg wrote:
> 
>  > arm*-*-netbsd*aout*  # submit your elf port already!
> 
> Krister Walfridsson still occasionally sends testsuite results for this
> target, and the last NetBSD ARM a.out release (1.5 branch) is not EOL'd
> yet, so please don't put this on the list.

To clarify a bit, I put every last target that was clearly (as in,
obvious from config.gcc) based on a.out or COFF on that list.  No
doubt several of them will have to stay.

zw

Re: It's target deprecation season again!

[David Edelsohn]

>>>>> Zack Weinberg writes:

Zack> The i370 and s390 targets are for the same architecture.  They are not
Zack> entirely redundant; each supports operating environments that the
Zack> other doesn't.  However, the s390 target is actively maintained, the
Zack> i370 isn't, and HOST_EBCDIC doesn't really work.  I would like to
Zack> suggest, therefore, that we drop (a) the i370, and (b) any pretense of
Zack> supporting EBCDIC as the primary character encoding for the host.  (It
Zack> is much, much easier to support it in the target.)

	The i370 port still is used for z/OS (aka OS/390 aka MVS) Unix
System Services.  I am not sure which port was used as the basis for the
TPF work which eventually should be merged into the FSF sources.

Zack> rs6000-ibm-aix[123]*
Zack> rs6000-ibm-aix4*  # maybe

	Huh?  It takes incrementally minimal effort to keep older AIX
configurations around and AIX 4.3 still is in wide-spread use.

David

Re: It's target deprecation season again!

[Russ Allbery]

Zack Weinberg <zack@codesourcery.com> writes:

> alpha*-dec-osf4*
> rs6000-ibm-aix4*  # maybe

I don't know whether anyone has been maintaining the gcc parts, but these
architectures certainly continue to be in widespread use.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: It's target deprecation season again!

[Hans-Peter Nilsson]

On Sat, 19 Oct 2002, Joseph S. Myers wrote:

> On Fri, 18 Oct 2002, Zack Weinberg wrote:
>
> > i?86-*-linux*libc1
>
> There are bug reports from people trying to use this (indicating it has
> been bitrotten since 3.0).  This can be interpreted as the presence of
> (attempted) users meaning it should be fixed, or the bitrottenness since
> 3.0 meaning it should just be removed.

FWIW, I guess I should help fixing this target as I sometimes
wish I had access to a newer gcc on one old system.

brgds, H-P

Re: It's target deprecation season again!

[Hans-Peter Nilsson]

On Fri, 18 Oct 2002, Zack Weinberg wrote:
> Moving on to specific targets that might be worth dropping, here is my
> list.

> cris-*-aout

No, this should *not* be dropped.  (There's no reasonable way to
abandon use of it, not due to eternal love for a.out...)

brgds, H-P
PS.  If that GCC conference will finally happen, I suggest it to
have one of those amusement park shooting galleries so people
can live out their urge to get rid of those targets. :-)  Oh no,
I'm suddenly associating a.out with that piece of chalk at the
end of a paper rose.  Better call it a day.

Re: It's target deprecation season again!

[Janis Johnson]

On Sat, Oct 19, 2002 at 04:07:25AM -0400, Hans-Peter Nilsson wrote:
> 
> PS.  If that GCC conference will finally happen, I suggest it to
> have one of those amusement park shooting galleries so people
> can live out their urge to get rid of those targets. :-)  Oh no,
> I'm suddenly associating a.out with that piece of chalk at the
> end of a paper rose.  Better call it a day.

I forwarded this to the conference committee.  I think it would be great
to have some activities like this.

Janis

Re: It's target deprecation season again!

[Joel Sherrill]

Mike Stump wrote:
> 
> On Friday, October 18, 2002, at 04:05 PM, Zack Weinberg wrote:
> > Of these, only ns32k has seen any activity other than global cleanups
> > since the 3.1 release.  So I propose to remove ns32k-*-* from the
> > deprecation list, and pull the plug on the others.
> 
> Sounds good.
> 
> > There was some discussion of dropping i960-*-*; I didn't see it come
> > to a conclusion.
> 
> The conclusion is that it should stay.  We should have a timeout list,
> and place i960 on it so that we can renominate it in 2-4 years time.

Did I miss something?  Did someone volunteer to maintain it?  I thought
it was going to be deprecated or even just removed ASAP if a maintainer
did not show up.  There was one last chance for someone at ACT to
speak and that was possibly the death blow if they say "not interested."

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: It's target deprecation season again!

[Mark Mitchell]

> There was some discussion of dropping i960-*-*; I didn't see it come
> to a conclusion.

The SC is presently voting on this, and looks extremely likely to approve
dropping this port.  I'm not sure whether the SC is supposed to vote on
these things, or not; I don't really think that it should have to.

I have no other specific comments; I'd like to see us remove as many
dead ports as possible.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: It's target deprecation season again!

[David O'Brien]

On Fri, Oct 18, 2002 at 04:05:08PM -0700, Zack Weinberg wrote:
> It's time to decide which targets should be deprecated for the 3.3
> release and removed in 3.4.
 
> i?86-*-freebsd*aout*

We actually still need this one.

-- 
-- David  (obrien@FreeBSD.org)

Re: It's target deprecation season again!

[Zack Weinberg]

On Fri, Nov 01, 2002 at 09:01:13PM -0800, David O'Brien wrote:
> On Fri, Oct 18, 2002 at 04:05:08PM -0700, Zack Weinberg wrote:
> > It's time to decide which targets should be deprecated for the 3.3
> > release and removed in 3.4.
>  
> > i?86-*-freebsd*aout*
> 
> We actually still need this one.

Can you expand on that a bit please?

zw

Re: It's target deprecation season again!

[David O'Brien]

On Sat, Nov 02, 2002 at 02:05:20AM -0800, Zack Weinberg wrote:
> On Fri, Nov 01, 2002 at 09:01:13PM -0800, David O'Brien wrote:
> > On Fri, Oct 18, 2002 at 04:05:08PM -0700, Zack Weinberg wrote:
> > > It's time to decide which targets should be deprecated for the 3.3
> > > release and removed in 3.4.
> >  
> > > i?86-*-freebsd*aout*
> > 
> > We actually still need this one.
> 
> Can you expand on that a bit please?

We are removing the a.out support in our dual a.out/ELF toolchain.
People that have been building a.out bits with the system compiler will
now have to use GCC built with the "i?86-*-freebsd*aout*" target.  Of
course we'll make a FreeBSD port to make installing it easier.  Believe

-- 
-- David	(obrien@FreeBSD.org)

Re: It's target deprecation season again!

[Adam Nemet]

Zack,

Sorry for the delay.

> i?86-*-lynxos*
> rs6000-*-lynxos*

I am planning to upgrade these ports to our (Lynuxworks) current
versions and also contribute our ARM port in the next couple of
months.  This will be a good time to decide if we want to keep COFF or
just replace them with the new ELF ports.

> sparc-*-lynxos*

AFAICT this is not supported by Lynuxworks anymore but I will check.

Adam

Re: It's target deprecation season again!

[Roman Leshchinskiy]

On Fri, 18 Oct 2002, Zack Weinberg wrote:

> alpha*-*-unicosmk*

Please don't drop this, it is being used and I intend to work further on
it when time permits. Sorry about answering so late but I don't even have
the time to read the mailing list regularily.

Bye

Roman

Re: It's target deprecation season again!

[Jason R Thorpe]

On Sat, Nov 02, 2002 at 05:44:50PM -0500, John David Anglin wrote:

 > > vax-*-ultrix*
 > 
 > Please don't depreciate unless you can find a new vax maintainer.  The
 > machine used for testing runs proprietary software so it can't be updated
 > to netbsd.

Have you heard about SIMH?  It's a suite of historical computer simulators.

There's a KA655 (MicroVAX 3800) in the package, and there's an experimental
DELQA module for it now, so you can have Ethernet if you run the sim on a
Win2k, Linux, or NetBSD host.

I'm running it on a 2GHz P4 Xeon (NetBSD 1.6 installed in the simulator),
and on that machine I'd definitely say it feels faster than my 4000/60
(which is itself a fairly speedy machine, in VAX terms).

	http://simh.trailing-edge.com/

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: It's target deprecation season again!

[John David Anglin]

> vax-*-vms* has already gone, and there was much rejoicing.

Hmmm, doesn't really look gone.

> hppa1.0-*-osf*
> hppa1.0-*-bsd*
> hppa1.[01]-*-hpux[789]*
> hppa*-*-hiux*
> hppa*-*-lites*
> hppa*-*-mpeix*

These all seem reasonable from my perspective.

> vax-*-ultrix*

Please don't depreciate unless you can find a new vax maintainer.  The
machine used for testing runs proprietary software so it can't be updated
to netbsd.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: It's target deprecation season again!

[DJ Delorie]

> > In libiberty/safe-ctype.c I added a complete case for EBCDIC, using a check like
> > #elif '\n' == 0x15 && ' ' == 0x40 && '0' == 0xF0 \
> >   && 'A' == 0xC1 && 'a' == 0x81 && '!' == 0x5A \
> >   && 'J' == 0xD1 && 'j' == 0x91 && EOF == -1
> 
> I'm sure DJ would appreciate a patch for this.

Yup, I would.

Re: It's target deprecation season again!

[Neil Booth]

Unruh, Erwin wrote:-

> I have run into a few problems with the EBCDIC support (in GCC 3.0.4):
> 
> In cppinit.c the static function "opt_comp" needs the definiton of "p1" and "p2"
> defined later in this file. The call to qsort needs the size of "struct
> cl_option" defined later in this file. I could solve this problem by
> re-ordering the function definitions in this file.

Please submit a patch against 3.2 and 3.3.  c-opts.c is similar and only
exists in 3.3; I'm not sure whether that has the same problem.

> In libiberty/safe-ctype.c I added a complete case for EBCDIC, using a check like
> #elif '\n' == 0x15 && ' ' == 0x40 && '0' == 0xF0 \
>   && 'A' == 0xC1 && 'a' == 0x81 && '!' == 0x5A \
>   && 'J' == 0xD1 && 'j' == 0x91 && EOF == -1

I'm sure DJ would appreciate a patch for this.
 
> In tradcif.y use TARGET_ESC instead of hardcoded "033".

tradcif is dead in 3.3 (yeah!), but a 3.2 patch would be welcome.

Neil.

Re: It's target deprecation season again!

[Unruh, Erwin]

> The i370 and s390 targets are for the same architecture.  They are not
> entirely redundant; each supports operating environments that the
> other doesn't.  However, the s390 target is actively maintained, the
> i370 isn't, and HOST_EBCDIC doesn't really work.  I would like to
> suggest, therefore, that we drop (a) the i370, and (b) any pretense of
> supporting EBCDIC as the primary character encoding for the host.  (It
> is much, much easier to support it in the target.)

I do not care about those two targets, but I do care for the EBCDIC support. We
(at FSC) are using GCC as an internal tool. It runs on a system with both host
and target being EBCDIC.

I have run into a few problems with the EBCDIC support (in GCC 3.0.4):

In cppinit.c the static function "opt_comp" needs the definiton of "p1" and "p2"
defined later in this file. The call to qsort needs the size of "struct
cl_option" defined later in this file. I could solve this problem by
re-ordering the function definitions in this file.

In libiberty/safe-ctype.c I added a complete case for EBCDIC, using a check like
#elif '\n' == 0x15 && ' ' == 0x40 && '0' == 0xF0 \
  && 'A' == 0xC1 && 'a' == 0x81 && '!' == 0x5A \
  && 'J' == 0xD1 && 'j' == 0x91 && EOF == -1

I had to re-create c-parse.c with an EBCDIC bison.

In tradcif.y use TARGET_ESC instead of hardcoded "033".


Please do not to drop the EBCDIC support.

Thanks

        Erwin

Erwin Unruh, Fujitsu Siemens Computers, C/C++ compiler group

Re: It's target deprecation season again!

[Ralf Corsepius]

Am Mon, 2002-10-21 um 23.20 schrieb Joern Rennecke:
> DJ Delorie wrote:
> > 
> > > I thought all the wince ports are based on coff?
> > 
> > DJGPP is COFF-based also, and it's certainly not going away.  Nor is
> > Cygwin.  I think he was referring only to the BSD-class targets, which
> > (I guess) are all ELF now.
> 
> He has listed sh-coff, which is still the only coff-based sh port that
> you can use out of the box for simulator testing from a single tree build.
sh-coff also is the basis for sh-rtems.

So depredicating sh-coff also means depredicating sh-rtems or forcing it
to switch to sh-rtemself, which (due to lack of experience with
sh-rtemself-gcc-3.2, sh-rtemself-gcc-2.9x was plain broken) I would want
to avoid.

Ralf

Re: It's target deprecation season again!

[Joern Rennecke]

DJ Delorie wrote:
> 
> > I thought all the wince ports are based on coff?
> 
> DJGPP is COFF-based also, and it's certainly not going away.  Nor is
> Cygwin.  I think he was referring only to the BSD-class targets, which
> (I guess) are all ELF now.

He has listed sh-coff, which is still the only coff-based sh port that
you can use out of the box for simulator testing from a single tree build.
(Correct me if I'm wrong and somebody has implemented an sh-wince emulating
 target for the simulator that can be run on *nix).

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: It's target deprecation season again!

[DJ Delorie]

> I thought all the wince ports are based on coff?

DJGPP is COFF-based also, and it's certainly not going away.  Nor is
Cygwin.  I think he was referring only to the BSD-class targets, which
(I guess) are all ELF now.

Re: It's target deprecation season again!

[Joern Rennecke]

> To clarify a bit, I put every last target that was clearly (as in,
> obvious from config.gcc) based on a.out or COFF on that list.  No
> doubt several of them will have to stay.

I thought all the wince ports are based on coff?

And since wince is so bad for debugging, it's good to have a coff target
that you can use as an analogy for testing and debugging.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658

Re: It's target deprecation season again!

[Mark Mitchell]

--On Sunday, October 20, 2002 09:22:46 PM -0400 Robert Dewar 
<dewar@gnat.com> wrote:

> ACT is definitely *not* stepping up to the place to act as maintainer. It
> is possibloe that some time in the future a current user of GCC 2 with the
> i960 wlil be interested in moving to GCC 3, but if that happens, the port
> can be revived at that time.

OK; that means we can deprecate i960 in GCC 3.3 and remove it in 3.4.

Patches to do that are pre-approved.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: It's target deprecation season again!

[Robert Dewar]

ACT is definitely *not* stepping up to the place to act as maintainer. It
is possibloe that some time in the future a current user of GCC 2 with the
i960 wlil be interested in moving to GCC 3, but if that happens, the port
can be revived at that time.