Bug ID: 86482
           Summary: arm vector instruction requiring allignment uses non
                    alligned input
           Product: gcc
           Version: 7.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot
          Reporter: kkr at danfoss dot com
  Target Milestone: ---

See this example on GodBolt:

This code:
struct SomeStruct
    SomeStruct(int var1, int var2, int var3, int var4);
    int var1;     
    int var2;   
    int var3;          
    int var4;      
SomeStruct::SomeStruct(int var1, int var2,
        int var3, int var4)
    : var1(var1)
    , var2(var2)
    , var3(var3)
    , var4(var4)

With these options:  -O3  -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=hard
(surprisingly, all of those options are relevant to reproduce the bug,
including setting the floating point abi used)

Instead of "-O3","-O1 -ftree-vectorize" also produces the guilty assembly

For gcc 7.2.1 for arm, (also reproduced on 7.3.0 and 6.4.1)

Produces this assembly:
SomeStruct::SomeStruct(int, int, int, int):
        sub     sp, sp, #16
        ldr     ip, [sp, #16]
        stm     sp, {r1, r2, r3, ip}
        vld1.64 {d16-d17}, [sp:64]
        vst1.32 {q8}, [r0]
        add     sp, sp, #16
        bx      lr

As far as i have been able to find, the instruction:
vld1.64 {d16-d17}, [sp:64]

Requires the input (the stack pointer) to be 64 bit aligned. (the best source
for that i have been able to find, is unfortunately this stack overflow post: )

But as far as i can see, no such guarantee can be made for the stack pointer in
this assembly code. 

Specifically, in our production code, we managed set a break-point on the
vld1.64 instruction (vld1.64 {d16,d17},[sp@64]), and at that point in time, SP
was 0x03077B44, actually executing that instruction then generated a

Reply via email to