On Fri, May 30, 2014 at 12:19 AM, Maciej W. Rozycki
ma...@codesourcery.com wrote:
On Wed, 28 May 2014, Richard Earnshaw wrote:
Ah, light dawns (maybe).
I guess the problems stem from the attempts to combine Neon with ARMv5.
Neon shouldn't be used with anything prior to ARMv7, since that's
On Wed, 28 May 2014, Richard Earnshaw wrote:
Ah, light dawns (maybe).
I guess the problems stem from the attempts to combine Neon with ARMv5.
Neon shouldn't be used with anything prior to ARMv7, since that's the
earliest version of the architecture that can support it.
Good to know,
Ah, light dawns (maybe).
I guess the problems stem from the attempts to combine Neon with ARMv5.
Neon shouldn't be used with anything prior to ARMv7, since that's the
earliest version of the architecture that can support it.
I guess that what is happening is that we see we have Neon, so start
On Wed, May 28, 2014 at 9:30 AM, Richard Earnshaw rearn...@arm.com wrote:
Ah, light dawns (maybe).
I guess the problems stem from the attempts to combine Neon with ARMv5.
Neon shouldn't be used with anything prior to ARMv7, since that's the
earliest version of the architecture that can
On Tue, 13 Aug 2013, Kyrylo Tkachov wrote:
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The recently added gcc.target/arm/pr58041.c test exposed a bug in the
backend. When compiling for NEON
On Tue, May 27, 2014 at 3:31 PM, Maciej W. Rozycki
ma...@codesourcery.com wrote:
On Tue, 13 Aug 2013, Kyrylo Tkachov wrote:
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The recently added
On 27/05/14 15:31, Maciej W. Rozycki wrote:
On Tue, 13 Aug 2013, Kyrylo Tkachov wrote:
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The recently added gcc.target/arm/pr58041.c test exposed a bug in the
On 27/05/14 15:47, Ramana Radhakrishnan wrote:
On Tue, May 27, 2014 at 3:31 PM, Maciej W. Rozycki
ma...@codesourcery.com wrote:
On Tue, 13 Aug 2013, Kyrylo Tkachov wrote:
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
On Tue, 27 May 2014, Ramana Radhakrishnan wrote:
Looking at the section on unaligned accesses, it seems that the
ldrb/strb-class instructions are the only ones that are unaffected by the
SCTLR.A bit and do not produce alignment faults in any case.
The NEON load/store instructions,
On Tue, 27 May 2014, Richard Earnshaw wrote:
Afterwards it is:
.L14:
vldrd16, [r3, #-16]
vldrd17, [r3, #-8]
add r3, r3, #16
cmp r3, r1
vst1.64 {d16-d17}, [r2:64]!
bne .L14
and the second VLDR instruction traps with SIGILL (the
On Tue, 27 May 2014, Ramana Radhakrishnan wrote:
Beforehand the code fragment in question produced was:
.L14:
sub r1, r3, #16
add r3, r3, #16
vld1.8 {q8}, [r1]
vld1 allows a misaligned load.
Can you point me at the relevant piece of documentation
On Tue, 27 May 2014, Kyrill Tkachov wrote:
This change however has regressed gcc.dg/vect/vect-72.c on the
arm-linux-gnueabi target, -march=armv5te, in particular in 4.8.
And what are all the configure flags you are using in case some one
has to reproduce this issue ?
Second that.
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The recently added gcc.target/arm/pr58041.c test exposed a bug in the
backend. When compiling for NEON and with -mno-unaligned-access we
end up
On 08/13/13 15:57, Kyrylo Tkachov wrote:
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The recently added gcc.target/arm/pr58041.c test exposed a bug in the
backend. When compiling for NEON and with
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The recently added gcc.target/arm/pr58041.c test exposed a bug in the
backend. When compiling for NEON and with -mno-unaligned-access we
end up generating the vld1.64 and vst1.64 instructions instead of
Hi Julian,
The recently added gcc.target/arm/pr58041.c test exposed a bug in the
backend. When compiling for NEON and with -mno-unaligned-access we
end up generating the vld1.64 and vst1.64 instructions instead of
doing the accesses one byte at a time like -mno-unaligned-access
expects.
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
Kyrylo Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The recently added gcc.target/arm/pr58041.c test exposed a bug in the
backend. When compiling for NEON and with -mno-unaligned-access we
end up generating the vld1.64
On 08/08/13 15:44, Kyrylo Tkachov wrote:
Hi all,
The recently added gcc.target/arm/pr58041.c test exposed a bug in the backend.
When compiling for NEON and with -mno-unaligned-access we end up generating
the vld1.64 and vst1.64 instructions instead of doing the accesses one byte at
a time like
18 matches
Mail list logo
