On Fri, May 30, 2014 at 12:19 AM, Maciej W. Rozycki
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 the
>> earlies
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,
On Wed, May 28, 2014 at 9:30 AM, 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.
>
>
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 to
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 ?
>
> Sec
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
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 trap
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 instructio
On 27/05/14 15:47, Ramana Radhakrishnan wrote:
On Tue, May 27, 2014 at 3:31 PM, 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 wrote:
Hi all,
The recently added gcc.target/arm/pr
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 wrote:
> Hi all,
>
> The recently added gcc.target/arm/pr58041.c test exposed a bug in
On Tue, May 27, 2014 at 3:31 PM, 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 wrote:
>> > >
>> > >> Hi all,
>> > >>
>> > >> The recently added gcc.target/arm/pr580
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 wrote:
> > >
> > >> Hi all,
> > >>
> > >> The recently added gcc.target/arm/pr58041.c test exposed a bug in the
> > >> backend. When compiling for NEO
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 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 gen
>
> On 08/09/13 11:01, Julian Brown wrote:
> > On Thu, 8 Aug 2013 15:44:17 +0100
> > 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 generatin
On 08/09/13 11:01, Julian Brown wrote:
On Thu, 8 Aug 2013 15:44:17 +0100
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 instruction
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
> >
On Thu, 8 Aug 2013 15:44:17 +0100
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 accesse
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 -
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 -mno-unaligned-access expects. This patch fi
19 matches
Mail list logo
