• TargetDeprecationFAQ

1. What is the criteria for proposing deprecation for a target?

• 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.

Those targets that are not considered alive using the above criteria, might be proposed to be deprecated.

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).

2. When will a deprecated target be removed from the code?

The general idea is to deprecate in one release cycle, and to delete in a subsequent cycle. Targets would require --enable-obsolete to build them in version X.Y, then the code (and documentation, testsuite support etc.) would be removed some time after version X.Y 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 X.Y branch if it is clear they would not affect other targets.

3. My favorite target is being deprecated, but there are a lot of users for this target. Does any part of the deprecation requirements take into account user base, or just developer base?

Neither, it is the tester base. Testing is needed to provide evidence that a target works, but in practice some developer work is needed to fix problems that show up in testing and without such work, target architectures are unlikely to remain working well between major releases.

The problem is that often users of ancient hardware will also be users of very old versions of the software; if they don't help test the latest code (the gcc trunk), then there's no way to tell whether the latest code actually works. Code that is not tested is almost always broken code.

4. But why remove something that works fine because it may rot in the future?

The interface between gcc and the back-ends changes fairly frequently, so it's necessary for a target to be maintained or it will cease to work.

It's particularly with the lack of test results that that situation becomes a problem. In the absence of test results, we will not notice when a particular target becomes broken.

Every port, working or not, imposes a certain amount of maintenance overhead. It also adds inertia, because a small change that affects every backend might discourage someone from making that change, even if it's the right thing to do.