From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 63A613858431; Thu,  4 Apr 2024 15:40:49 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 63A613858431
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1712245249;
	bh=8jDh5ZvSTBB6RVD7MOKEhSXCTymko3qOwpSeCcmkWPw=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=sTqEyL0ODUDMoI6LdWgJaccptncd0bqi71pj7qpS6s8q56nMM/QO7PsWVAB5gD13N
	 ScIBsA5awy3dlXQZLZArZokjF7+OmYaYWob6OWEibMRxx3AN/jJaVr7oTR1+68kVZj
	 jAtLHe8sDWZJRyTrYyQxqkHIz802b2BaBE+qcnUU=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/114566] [11/12/13 Regression] Misaligned vmovaps when
 compiling with stack-protector-strong for znver4
Date: Thu, 04 Apr 2024 15:40:47 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 13.2.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114566-4-hiPacamQNC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114566-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114566-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114566

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, the a array which is the object into which the misaligned store happe=
ns
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 wh=
en
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))=