> 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 th
On Mon, 2010-06-28 at 01:37 +0100, Martin Guy wrote:
> On 6/27/10, Gerald Pfeifer 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
>
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 ar
On 6/27/10, Gerald Pfeifer 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 to do things.
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 tha
On 5/24/10, Mark Mitchell 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
> broken that c
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 spec
> 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
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-
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 f
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
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 maint
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
(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
maint
On Mon, 2010-05-24 at 12:42 +0200, Steven Bosscher wrote:
> On 5/24/10, Richard Earnshaw wrote:
> >
> > On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
> >> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell
> >> wrote:
> >> > Martin Guy wrote:
> >> >
> >> >> Dropping FPA support from GCC
On 5/24/10, Richard Earnshaw wrote:
>
> On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
>> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell
>> wrote:
>> > Martin Guy wrote:
>> >
>> >> Dropping FPA support from GCC effectively makes the OABI unusable, and
>> >> often we are forced to use
On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell 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
> >>
On Sun, 2010-05-23 at 05:11 +0100, Martin Guy wrote:
> On 5/11/10, Mark Mitchell 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
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,
> os
On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell 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
>> re
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 maintainabili
On 5/11/10, Mark Mitchell 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
22 matches
Mail list logo
