This is the mail archive of the
mailing list for the GCC project.
Proposed targets to obsolete for 3.5, first pass
- From: Steven Bosscher <steven at gcc dot gnu dot org>
- To: gcc at gcc dot gnu dot org
- Cc: Zack Weinberg <zack at codesourcery dot com>,Nathanael Nerode <neroden at twcny dot rr dot com>
- Date: Sun, 20 Jun 2004 17:39:18 +0200
- Subject: Proposed targets to obsolete for 3.5, first pass
- Organization: SUSE Labs
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
These targets have already been removed from GDB. 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.
The most recent post of someone interested in the VAX was in April
last year, 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.
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.
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, but this hasn't happened so far.
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 are not mighty impressive either, but nobody
appears to be interested in fixing them. In fact, no bugs were even
reported for it.
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.
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. 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.
(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
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
I'll post a separate email with some proposed rules later today.