Proposed targets to obsolete for 3.5, first pass

[Steven Bosscher <steven at gcc dot gnu dot org>]

Hi,

So here we go again.  I talked to people who have done this before
and don't feel like trying again for being flamed and not achieving
enough.  Since somebody has to do it, and do it early in the release
cycle, I decided to take a shot at it...

So, here it is, the short but perhaps-not-so-modest

------------------------------------------------------------------------
PROPOSED LIST OF TARGETS TO BE OBSOLETED FOR GCC 3.5

sparclet-*
  These targets have already been removed from GDB[1].  In previous
  discussions[2, 3] someone stepped forward to bring the target up to
  date, but nothing has happened since, afaict.  And really, are there
  "1000s of us using this sparclet-aout port" that really need the
  latest gcc?  In that case, it would be nice if somebody could post
  test results for it.  This has never happened as far as I can tell.

  [1] http://sources.redhat.com/ml/gdb-patches/2003-04/msg00166.html
  [2] http://gcc.gnu.org/ml/gcc/2003-04/msg00808.html
  [3] http://gcc.gnu.org/ml/gcc/2003-04/msg01133.html

vax-*
  The most recent post of someone interested in the VAX was in April
  last year[4], and it looked more like a joke than a serious interest
  in the port (but you really should have look at the pictures of the
  guy's "micro"-VAX box: http://williambader.com/museum/vax/vax.html).
  Everone knows VAX is old.  Nobody has been manufacturing VAXes
  since 1992.  There is no known free simulator, it is does not have
  any ELF targets, it has a cc0 backend, and the most recent test
  results I could find are more than two years old[5].
  For GCC 3.4, vax-*-* was already obsoleted.  I'm not sure why vax-*
  should stay, and I couldn't figure it out from earlier discussions.

  [4] http://gcc.gnu.org/ml/gcc/2003-03/msg00721.html
  [5] http://gcc.gnu.org/ml/gcc-testresults/2002-09/msg00774.html

i?86-*-lynxos*
rs6000-*-lynxos*
  No test results ever reported.  Would allow the complete removal of
  quite a few files.  There was an announcement of plans by Adam Nemet
  to bring these ports up-to-date[6], but this hasn't happened so far.

  [6] http://gcc.gnu.org/ml/gcc/2003-10/msg00306.html

fr30-*
  Removed from GDB already.  Only 120 lines touched in 2003 and 2004,
  mostly from updating to target hooks and ISO C prototypes.  It is
  unknown if a hardware implementation exists, or is being manufactured.
  The simluator that was in cvs/src/ appears to have been removed.  The
  test results I found[7] are not mighty impressive either, but nobody
  appears to be interested in fixing them.  In fact, no bugs were even
  reported for it.

  [7] http://gcc.gnu.org/ml/gcc-testresults/2003-06/msg00116.html

ip2k-*
  The port does everything we try to avoid these days: cc0, does not use
  define_constants, it uses assembly prologues/epilogues, etc.  There
  are three bugs open for this target (PR13749, PR13754, and PR 13817)
  that prevent it from producing code with a cross-compiler, for even the
  most trivial C input.  Test results have never been reported for ip2k.
  Again, most work on this ports was done by people doing ISO C90 proto
  work and such, hardly any actual maintainance on the port was done in 
  the past 2 years.

ns32k-*
  Nobody is manufacturing these old beasts.  And again, the only
  maintainance done on this port is making sure that it still builds.
  There are no test results from the past year, the latest results posted
  are from December 2002[8].  In addition, this is another cc0 target,
  it is unknown if a free simulator exists, the port uses assembly
  prologues/epilogues, it does not use define_constants.  In short, old
  stuff that few still use/test, if anyone at all.

  [8] http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg00799.html
------------------------------------------------------------------------
(Let the flame fest begin!)

The previous list by Nathaneal Nerode was more aggressive (find it here:
http://gcc.gnu.org/ml/gcc/2003-10/msg00143.html), but quite successful
since almost all proposed targets were also actually removed.

The above list is somewhat different than earlier obsoleted target lists
in that I have focused on architectures that are either very old or 
poorly maintained.  This is still very aggressive in the view of many
of y'all.  The reason for my choices is that I really don't believe gcc
has to carry around so much old stuff for newer releases.  Really, who
_has_ to to use gcc 3.5 to compile for, say, VAX?  Should all gcc
contributors be burdened with the maintainance costs of such very old
targets?

Of course, Zack and  Nathaneal have done this before and perhaps know
of other specific targets they would like to declare obsolete. 

Instead I'd like to discuss a _policy_ for obsoleting targets, because
what we do is really just randomly pick old targets and drop them.  GCC
"supports" so many targets that some manufacturer or contractor company 
contributed and then basically left it as a maintainance burden on the
rest of gcc that some set of rules is apparently necessary to prevent
that from happening. We can't keep claiming to maintain all ports when
the reality is that we have no way to know if the port still works.  For
that, we need more active involvement from the target contributors and
maintainers.
I'll post a separate email with some proposed rules later today.

Gr.
Steven