This is the mail archive of the 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 Mon, 2010-05-24 at 11:33 +0000, Joseph S. Myers wrote:
> (I've CC:ed the listed GCC maintainers for various OS ports whose ARM 
> configurations in GCC do not appear to be using EABI, as well as Pedro for 
> WinCE, given the discussions of deprecation.)  Deprecations are generally 
> a matter for the relevant maintainers, which in this case means target 
> maintainers together with OS maintainers (or target maintainers alone if 
> noone is maintaining the OS ports to ARM).
> On Mon, 24 May 2010, Richard Earnshaw wrote:
> > 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.
> What ABI does WinCE use?  

Don't know.  Does a document specifying it even exist?  If we are
supporting an ABI, then I think we need to have a publicly available

> I don't think it's EABI-based; it's not even 
> ELF.  When you're dealing with an OS not built with GCC, GCC gets to 
> follow the ABI defined for that OS, just like the x86_64 Windows port has 
> to deal with ABI differences from the ELF psABI for x86_64, for example.
> For OSes built with GCC (which I think is all the non-WinCE ARM targets) 
> there is more of a scope for transitioning to a new ABI and not supporting 
> old OS versions (and so removing arm-linux, arm-elf).
> I recently noted that VxWorks is not yet using EABI - but is certainly 
> still supporting ARM.  Now, if it transitions, I think it was established 
> some years ago that GCC does not generally try to support older VxWorks 
> versions.
> Is the ARM RTEMS port going to move to EABI?

Ask the maintainers.  Do they still want their OS to work on modern CPUs
with any degree of efficiency?  The current ABI diverged from the old
for good technical reasons, not just for the sake of being different.

> Are the ARM ports of FreeBSD or NetBSD moving to EABI?  (I think we can 
> kill the arm*-*-netbsd* that don't match arm*-*-netbsdelf* - i.e., old 
> a.out-based NetBSD - and more generally any other a.out BSD ports.)  Old 
> in-tree GCC versions shouldn't be a limitation here - 4.1 has EABI 
> support.

The NetBSD developers said at the time that they moved to arm-netbsdelf
that the ABI was transitional and that they would move to the EABI once
it was finished.  They've not made much effort to do that move (though I
admit as a NetBSD developer, I've not done much pushing).  Consider this
the first heave :-)  I don't know about FreeBSD; and I'm not aware that
they've ever done anything other than follow NetBSD in this area.

> Is there anyone maintaining arm*-*-ecos-elf?
> I hope none of the above ports are using FPA.

I don't think so.  Certainly NetBSD doesn't; I can't speak for the rest.
In fact, I'm pretty sure that only the old linux ABI uses the FPA.

Certainly removing support for FPA (and any targets that require it) as
a first step would be an option; but we should also focus on where we
want to get to.  Setting our plans out would be the best option for
those who need to change, so that they have sufficient opportunity to
plan their own work and avoid unnecessary intermediate steps (it would
be very unfair, for example, to suggest to those who need to migrate
away from using the FPA to just move to using soft-float arm-elf if they
then find twelve months down the line that they have to move again
because arm-elf was going away as well.



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