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

["Joseph S. Myers" <joseph at codesourcery dot com>]

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

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.

Is there anyone maintaining arm*-*-ecos-elf?

I hope none of the above ports are using FPA.

-- 
Joseph S. Myers
joseph@codesourcery.com