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
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 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
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
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,
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.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385
On 04/29/2010 06:06 PM, Joseph S. Myers wrote:
On Thu, 29 Apr 2010, Joel Sherrill wrote:
Hi,
I am looking at the arm-rtems test results for the
trunk and noticing that most failures appear to be
for neon tests.
[j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | wc -l
2203
[j...@rtbf64a gcc]$
On Fri, 30 Apr 2010, Joel Sherrill wrote:
This is fairly typical.
FAIL: gcc.target/arm/neon/vzips8.c (test for excess errors)
Excess errors:
vzips8.s:13: Error: selected processor does not support `fldd d17,[fp,#-40]'
[...]
Would it be better for the arm_neon_ok check to actually put
in
On 04/30/2010 09:37 AM, Joseph S. Myers wrote:
On Fri, 30 Apr 2010, Joel Sherrill wrote:
This is fairly typical.
FAIL: gcc.target/arm/neon/vzips8.c (test for excess errors)
Excess errors:
vzips8.s:13: Error: selected processor does not support `fldd d17,[fp,#-40]'
[...]
Would
On Fri, 30 Apr 2010, Joel Sherrill wrote:
For EABI, this is done
with .cpu, .arch and .fpu directives; for non-EABI you may need to write
specs to pass command-line options to the assembler. Creating an
arm-rtemseabi or similar target and obsoleting the old-ABI version is what
I'd
On Fri, 2010-04-30 at 15:26 +, Joseph S. Myers wrote:
On Fri, 30 Apr 2010, Joel Sherrill wrote:
For EABI, this is done
with .cpu, .arch and .fpu directives; for non-EABI you may need to write
specs to pass command-line options to the assembler. Creating an
arm-rtemseabi or
Hi,
I am looking at the arm-rtems test results for the
trunk and noticing that most failures appear to be
for neon tests.
[j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | wc -l
2203
[j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | grep /neon/ | wc -l
1986
On Thu, 29 Apr 2010, Joel Sherrill wrote:
Hi,
I am looking at the arm-rtems test results for the
trunk and noticing that most failures appear to be
for neon tests.
[j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | wc -l
2203
[j...@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | grep /neon/ | wc
22 matches
Mail list logo
