Re: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb

["Maciej W. Rozycki" <macro at codesourcery dot com>]

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, including vld1.8 can still cause an
> >> alignment fault when SCTLR.A is set. So it seems we can only use the byte-wise
> >> core memory instructions for unaligned data.
> >
> >  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 ?

 There was nothing relevant to code generation among these flags except 
from --with-arch=armv5te, but this architecture selection I already 
included above.

> >  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.
> 
> >         cmp     r3, r0
> >         vst1.64 {d16-d17}, [r2:64]!
> >         bne     .L14
> >
> > Afterwards it is:
> >
> > .L14:
> >         vldr    d16, [r3, #-16]
> >         vldr    d17, [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 value in R3 is
> > 0x10b29, odd as you'd expect, pointing into `ib').  I don't know why and
> > especially why only the second of the two (regrettably I've been unable to
> > track down an instruction reference that'd be detailed enough to specify
> > what exceptions VLDR can produce and under what conditions).
> 
> vldr will cause an unaligned access fault if the address is
> misaligned. The question is why is the address misaligned in this
> case.

 The address is unaligned because odd indexes into `ib' are accessed, 
which is defined as:

char ib[N+1];

I'd say the question is rather why VLDR is used to access that array where 
clearly it can't be.  The loop copies a chunk of data in 64-bit quantities 
between two memory areas of which one is 64-bit aligned and the other is 
not.  So while 32-bit or 64-bit aligned accesses can still be used to do 
it, they can't be for both areas at a time, unless some further data 
manipulation is done such as shifting and merging.

  Maciej