This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)


On Sun, 2010-05-23 at 05:11 +0100, Martin Guy wrote:
> On 5/11/10, Mark Mitchell <mark@codesourcery.com> wrote:
> > Richard Earnshaw wrote:
> >
> >  > Speaking of which, we should probably formally deprecate the old arm-elf
> >  > derived targets in 4.6 so that we can remove them in 4.7.
> >
> >  > Similarly, we should deprecate support for the FPA on ARM.
> >
> >  I agree.
> 
> No one seems to have succeeded in getting arm-elf to work for some
> years, so removing them seems to be no loss.
> 

If nobody is building and testing it, then this will happen.  It's why
we should deprecate it.  That way, users are aware of the fact that the
configuration might not work and will probably go away at some point.

> However, although no one currently sells FPA hardware, 

That's overstating it.  Currently?  I don't expect anyone to ever sell
it again.

> it is widely
> supported as the only floating point model emulated by the Linux
> kernel, and people have to use it when compiling stuff to run on OABI
> systems, which include boards currently on the market based on ARMv4
> (no t) such as the Balloon Board 2.0 as well as boards with more
> recent CPUs where the manufacturer only supplies a LInux port for a
> kernel version that predates EABI support such as the Armadillo range.

OABI should be on the deprecated list too, as should all ports that
derive from the APCS or ATPCS rules.  The point of this deprecation
process is to allow us to sort out a lot of historical kinks in the
compiler.

Lets face it: strongarm was the last v4 chip to be produced, that's now
15 years old.  If gcc-4.6 were to be the last compiler to support it,
then it would still be supported for at least two years following its
release in (presumably) 2011 ie until at least 2013, by which time it
will be 18 years old.  I think that ought to be enough of a life-span.

> 
> 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?

Debian dropped OABI after Lenny, I've not heard anybody complain about
that.  That was the last major distro to use it.

Don't forget that the cost is not just on GCC, it's on all the tools --
gas, gdb, binutils -- the list goes on.

As for technical difficulties, then there's the odd format of doubles
that makes for much confusion for users, the mess of the old attributes
used in the old ABI variants and the fact that they were implemented
incorrectly...

It's time we faced up to the fact that the old code is not going to be
sorted out properly; that there's a maintained and well specified
compiler port out there that is not only capable of supporting v4 but is
also future-proofed as much as we can make it; that the old ports are
not being tested, so are most likely buggy by now and that all this
legacy bloat has a cost that we all must bear if we keep refusing to do
anything about it.

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]