https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, the a array which is the object into which the misaligned store happens
has
align:128 so assuming 256-bit alignment into it seems wrong:
(insn 57 56 58 4 (set (reg:V8SF 135 [ vect__33.37 ])
        (plus:V8SF (reg:V8SF 101 [ vect_b_6.33 ])
            (mem:V8SF (plus:DI (reg/f:DI 83 [ _42 ])
                    (const_int 192 [0xc0])) [1 MEM <vector(8) float> [(float
*)_42 + 192B]+0 S32 A256]))) "pr114566.c":16:12 2077 {*addv8sf3}
     (nil))
(insn 58 57 59 4 (set (mem:V8SF (plus:DI (reg/f:DI 83 [ _42 ])
                (const_int 192 [0xc0])) [1 MEM <vector(8) float> [(float *)_42
+ 192B]+0 S32 A256])
        (reg:V8SF 135 [ vect__33.37 ])) "pr114566.c":16:12 1847
{movv8sf_internal}
     (nil))
It should have been A128, not A256...
For the vaddps we get away with that because AVX allows misaligned loads when
used in arith instructions, but not for the store.
But the neighbouring loads/stores use correct alignment:
(insn 54 53 55 4 (set (reg:V16SF 133 [ vect__47.22 ])
        (mem:V16SF (plus:DI (reg/f:DI 83 [ _42 ])
                (const_int 128 [0x80])) [1 MEM <vector(16) float> [(float *)_42
+ 128B]+0 S64 A128])) "pr114566.c":16:8 1846 {movv16sf_internal}
     (nil))
(insn 55 54 56 4 (set (reg:V16SF 134 [ vect__48.23 ])
        (plus:V16SF (reg:V16SF 133 [ vect__47.22 ])
            (reg:V16SF 96 [ vect_b_46.19 ]))) "pr114566.c":16:12 2069
{*addv16sf3}
     (nil))
(insn 56 55 57 4 (set (mem:V16SF (plus:DI (reg/f:DI 83 [ _42 ])
                (const_int 128 [0x80])) [1 MEM <vector(16) float> [(float *)_42
+ 128B]+0 S64 A128])
        (reg:V16SF 134 [ vect__48.23 ])) "pr114566.c":16:12 1846
{movv16sf_internal}
     (nil))

Reply via email to