GCC 4.3 target deprecation proposals

["Joseph S. Myers" <joseph at codesourcery dot com>]

No targets have been deprecated since 4.0, so it seems time to
consider deprecating unused targets again.  The usual procedure would
apply: targets would require --enable-obsolete to build them in 4.3,
then the code (and docs, testsuite support etc.) would be removed some
time after 4.3.0 is released if no-one comes forward to resurrect the
target support.  If someone does come forward, patches to resurrect
the support could be accepted even in the 4.3 branch if it is clear
they would not affect other targets.

First, I propose removing c4x support, which has been in the obsolete
state since 4.0 without being removed.  This does not mean removal of
any support or abstractions present elsewhere in the compiler to
support non-8-bit bytes; just c4x-specific code.

I have applied the following methodology to choose targets to propose
obsoleting:

* Any target with test results posted to gcc-testresults within the
past year, or mentioned on gcc-patches within the last year as having
been used to test a patch (not just building cc1; testing that the
resulting compiler works), is considered alive and not proposed for
deprecation.  OS version numbers etc. that don't affect the GCC
configuration are not considered significant; other slight variants
with the same architecture and OS may also be accepted as alive
without needing test results for every variant target triplet.
(Though some such triplets might better be handled with configure
options such as --with-arch and --with-abi.)

The principle here is that any target (especially any target
architecture) involves maintenance cost for many global patches; as
such, maintainer responsibilities include testing and sending test
results from time to time to show that the target still works, and
fixing problems arising from changes to core code.  If you cannot
maintain a target on an ongoing basis, posting the patch to
gcc-patches and assigning to the FSF, but explicitly without proposing
addition to GCC trunk, may serve the purpose of making the patch
available to anyone wishing to use it without imposing the cost on GCC
maintenance.

* If any target from an architecture is alive, generic targets such as
-elf -coff -aout -eabi -pe for that architecture are also considered
alive.  If an OS is alive for some architectures it may also be
considered alive for others unless there is reason to believe that the
combination is no longer alive despite both OS and architecture being
alive.

The following target architectures have seen no test results posted in
the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11,
score, stormy16, vax.  Of these targets, score appears to be actively
maintained; I suggest that the SC appoint Chen Liqin
<liqin@sunnorth.com.cn> as the official maintainer of this port, if
not already done, and I suggest to Chen Liqin that he add himself to
the MAINTAINERS file and start posting test results for this port to
gcc-testresults using the contrib/test_summary script.  I found
mention of one patch having been tested on vax-netbsdelf; I encourage
the maintainers to try to run the testsuite and send testresults for
trunk at least once a year.

Of the others: arc, crx, iq2000, mt, pdp11, stormy16, I see no recent
testing or development.  Joern Rennecke was intending to improve ARC
support but is listed as "Waiting for paperwork" in MAINTAINERS; is
there any news on that assignment?  I propose obsoleting crx, iq2000,
mt, pdp11 and stormy16 unless someone steps forwards and indicates
that they have recently tested trunk for one of those targets and it
is working, or that they intend to test trunk and ensure it is in good
shape for their target before 4.4 is released.  Intentions would not
in my view suffice if the same intentions have been expressed for the
same target in response to a previous deprecation proposal, although
the final approval of target deprecations is up to a global write
maintainer or the SC.

I will consider deprecations of individual targets for architectures
separately depending on the reaction to this deprecation proposal.
People may also make their own proposals for deprecations, including
relating to targets which have had results posted in the past year,
and including deprecations of particular subconfigurations (e.g. using
a particular target without the GNU assembler, or with a particular
debug format).  I note the lack of anyone posting test results for
uClinux, OpenBSD or RTEMS, and suggest that users of those operating
systems should try to post test results for at least some target
architectures.

The list of targets for which I found test results is attached.

-- 
Joseph S. Myers
joseph@codesourcery.com

Attachment: targets-tested-2007
Description: Text document