armv7+neon bus error

[Andrei Kazmin via Gcc]

Hello,

 

I built gcc for armv7+neon target with 128-bit stack alignment to enable
ASan with custom shadow memory scale. I got bus error in runtime for some of
utils built with the toolchain. I checked disassembler output and found that
sometimes gcc vectorizes assignments at the ASan epilogue of functions. But
it generates VSTR instruction for unaligned memory accesses which leads to
bus error condition.

 

I have the following gimple assignment in gcc:

 

  tree magic = build_int_cst (TREE_TYPE (shadow_ptr_type), val);

 

  tree dest = build2 (MEM_REF, TREE_TYPE (shadow_ptr_type), shadow,

              build_int_cst (shadow_ptr_type, base_addr_offset));

 

  gimple *g = gimple_build_assign (dest, magic);

 

It generates the following instructions:

 

    9b16:    f109 5300     add.w    r3, r9, #536870912    ; 0x20000000

    9b1a:    efc0 0010     vmov.i32    d16, #0    ; 0x00000000

    9b1e:    edc3 0b00     vstr    d16, [r3]

    9b22:    edc3 0b01     vstr    d16, [r3, #4]

 

At the expand stage I have the following tree dump related to the case:

 

(insn 56 55 57 311 (set (reg/f:SI 867)

        (plus:SI (reg:SI 856)

            (const_int 536870912 [0x20000000]))) "ls.c":1394:1 -1

     (nil))

(insn 57 56 58 311 (set (reg:SI 868)

        (reg/f:SI 867)) "ls.c":1394:1 -1

     (nil))

(insn 58 57 59 311 (set (reg:V8QI 869)

        (const_vector:V8QI [

                (const_int 0 [0]) repeated x8

            ])) "ls.c":1394:1 -1

     (nil))

(insn 59 58 60 311 (set (mem:V8QI (reg:SI 868) [33  S8 A32])

        (reg:V8QI 869)) "ls.c":1394:1 -1

     (nil))

(insn 60 59 61 311 (set (mem:V8QI (plus:SI (reg:SI 868)

                (const_int 4 [0x4])) [33  S8 A32])

        (reg:V8QI 869)) "ls.c":1394:1 -1\

     (nil))

 

I doesn't have enough experience with gcc internals to figure out why gcc
generates the code above.
And what conditions are met, which leads to the usage of vector instructions
with unaligned addresses

Any tips will be appreciate.

 

Thanks,

Andrei Kazmin