This is the mail archive of the
mailing list for the GCC project.
Re: m68k MacOS target support?
- To: mark at codesourcery dot com (Mark Mitchell)
- Subject: Re: m68k MacOS target support?
- From: Joe Buck <jbuck at racerx dot synopsys dot com>
- Date: Tue, 12 Sep 2000 11:14:49 -0700 (PDT)
- Cc: lars at nocrew dot org, meissner%cygnus dot com dot binutils at sources dot redhat dot com, gcc at gcc dot gnu dot org
> lars> I certainly don't expect the maintainers to actively
> lars> maintain the PDP-10 back end, or even care much if it
> lars> breaks.
> What's funny about these kinds of things is how hard it is to undo
> anything. Whenever I propose getting rid of a "feature" in GCC, I
> find that people now rely on that feature, or that at least many
> people are afraid people rely on that feature. Support for a platform
> is a feature. Once support is in GCC, it will probably be somewhat
> difficult to remove that support.
The approach gcc has taken to this problem in the past (whether we want
to admit it or not) is to just let the uninteresting ports slowly degrade
due to bit rot. This has the disadvantage that it can make gcc look bad,
but if a committed user comes along at some point there is hope that the
broken port can be fixed. Given this it is probably better to leave the
ports in, with warnings about which ones have been tested and which ones
are likely to have problems.
A partially broken port doesn't have a negative impact on users of other
ports. Features accessible from the front end, on the other hand, have
a bigger impact, as they can slow down all future compiler development.
Everyone working on optimizations or trying to track moving language
standards has to waste time figuring out how to do the special case
code for handling the case where the "feature" is used.