However, although no one currently sells FPA hardware, 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
On Mon, 2010-06-28 at 01:37 +0100, Martin Guy wrote:
On 6/27/10, Gerald Pfeifer ger...@pfeifer.com wrote:
On Mon, 24 May 2010, Richard Kenner wrote:
I think that's a critical distinction. I can't see removing a port just
because it's not used much (or at all) because it might be
On Mon, 24 May 2010, Richard Kenner wrote:
I think that's a critical distinction. I can't see removing a port just
because it's not used much (or at all) because it might be valuable for
historical reason or to show examples for how to do things. If the
maintenance burden of keeping that
On 6/27/10, Gerald Pfeifer ger...@pfeifer.com wrote:
On Mon, 24 May 2010, Richard Kenner wrote:
I think that's a critical distinction. I can't see removing a port just
because it's not used much (or at all) because it might be valuable for
historical reason or to show examples for how
Martin Guy wrote:
For
ARM boards without mainline Linux support whose manufacturers' kernel
ports predates 2.6.16, it is mandatory, as is also is for users who
just want to compile code for a given existing system that happens not
to be running a recent kernel and userspace.
But what are
On Sun, 2010-05-23 at 05:11 +0100, Martin Guy wrote:
On 5/11/10, Mark Mitchell m...@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
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
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
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
(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
On Mon, 24 May 2010, Steven Bosscher wrote:
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.
Nb, I don't oppose deprecating any arm stuff, but I just would like to
know if the
On 05/24/2010 06:33 AM, 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
On Mon, 24 May 2010, Joel Sherrill wrote:
The question we would like answered is what impact this
has on our code base. What changes will we have to
make to accomodate this? Register usage changes, stack
frame changes, etc.
For ARM Linux, one change was dealing with __arm__ conditionals in
On Mon, 2010-05-24 at 11:33 +, 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
On Mon, 2010-05-24 at 06:40 -0500, Joel Sherrill wrote:
The question we would like answered is what impact this
has on our code base. What changes will we have to
make to accomodate this? Register usage changes, stack
frame changes, etc.
By far the biggest change is to the layout of 64-bit
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.
The vax back-end only affects VAX; likewise for the PDP11 port.
I think that's a critical distinction. I can't see removing a port
just because it's not used much
Richard Earnshaw wrote:
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
SPEC.
I disagree with that statement. If a system is sufficiently popular, we
probably want to support it -- with or without a
On 5/24/10, Mark Mitchell m...@codesourcery.com wrote:
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.
I agree with that. But, it would also be interesting to know just how
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
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,
Steven Bosscher wrote:
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,
21 matches
Mail list logo
