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-338
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-r
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
>
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 i
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 p
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 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
