On Mon, 2010-05-24 at 12:42 +0200, Steven Bosscher wrote:
> On 5/24/10, Richard Earnshaw <rearn...@arm.com> wrote:
> >
> > On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
> >> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell <m...@codesourcery.com>
> >> wrote:
> >> > Martin Guy wrote:
> >> >
> >> >> Dropping FPA support from GCC effectively makes the OABI unusable, and
> >> >> often we are forced to use that by the environment supplied to us. Are
> >> >> there significant advantages to removing FPA support, other than
> >> >> reducing the size of the ARM backend?
> >> >
> >> > I think that maintainability of the ARM backend is indeed the major
> >> > benefit to dropping it.
> >>
> >> There are lots of other ports that could be dropped to improve
> >> maintainability of some backends, or even the whole of GCC. That has
> >> never been accepted as a good reason to drop anything if there are
> >> still users of it, no matter how few (see pdp11 / vax backends,
> >> osf/tru64 support, other random unmaintained backends, ...).
> >>
> >> What is different about arm-elf?
> >>
> >
> > What's different is that there is a well-maintained arm-eabi port.  The
> > arm-elf port and all its legacy just gets in the way.
> >
> 
> Imho you are taking a too narrow view here, because...
> 
> > The vax back-end only affects VAX; likewise for the PDP11 port.
> 
> ...all this legacy just gets in the way of gcc as a whole. So I still
> don't see the difference.
> 

To a degree, yes, you are right.  However, the source for all that port
is in separate files.  For the ARM port this is all necessarily in one
place.

> Nb, I don't oppose deprecating any arm stuff, but I just would like to
> know if the justification also applies to other backends/ports.
> Patched from me and others were rejected in the past even though the
> situation was similar. Under what criteria would such patches now get
> support from the RMs?
> 

Can't really answer that one.  I don't remember the case; and anyway,
it's not me that gets to decide...


R

Reply via email to