From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C3BB03858C62; Thu, 4 Apr 2024 16:33:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C3BB03858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712248419; bh=cGMFL2CGyIK94yZfak5WPWmKdedSaOK6W/0LUzgirzE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Rfu+xfy6hyF2sgYFwKxLuDxoB1fBkljcPj4oimIiW0aoVdGXGqJ86TO7Nl7azponM w/ap1gVZ7JE0abBLCiKhhvL391UhPy9FePNl4dWfx8DDnZFIK2kZZZ7acqKEY4o6v0 z9K4CHqsQ6zl/siV40cl4mViNIICRKbQxd/JfR6I= From: "jakub at gcc dot 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 16:33:39 +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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114566 --- Comment #12 from Jakub Jelinek --- The user align:32 MEM_REF comes from (gdb) p debug (dr_info->dr) #(Data Ref:=20 # bb: 21=20 # stmt: a[j_38][k_41] =3D _48; # ref: a[j_38][k_41]; # base_object: a; # Access function 0: {0, +, 1}_3 # Access function 1: j_38 #) $34 =3D void (gdb) p *dr_info $35 =3D {dr =3D 0x3a1be60, stmt =3D 0x3a1ef10, group =3D 21, misalignment = =3D -1, target_alignment =3D {> =3D {coeffs =3D {64}= }, },=20 base_misaligned =3D false, base_decl =3D , offset =3D } (gdb) p *dr_info->dr $36 =3D {stmt =3D , ref =3D , aux =3D 0x0, is_read =3D false, is_conditional_in_stmt =3D false, alias =3D= {ptr_info =3D 0x0}, innermost =3D { base_address =3D , offset =3D , init =3D , step =3D , base_alignment =3D 16,=20 base_misalignment =3D 0, offset_alignment =3D 32, step_alignment =3D 4}= , indices =3D {base_object =3D , access_fns =3D {m_vec =3D 0x= 383ebb0 =3D {0x7fffea058618,=20 0x7fffea03fdc8}}, unconstrained_base =3D false}, alt_indices =3D {base_object =3D , access_fns =3D {m_vec =3D 0x0}, unconstrained_= base =3D false}} dr in vectorizable_store, alignment_support_scheme is dr_unaligned_supported and so build_aligned_type is done: 8694 data_ref =3D fold_build2 (MEM_REF, vectype, 8695 dataref_ptr, 8696 dataref_offset 8697 ? dataref_offset 8698 : build_int_cst (ref_type, 0)); 8699 if (alignment_support_scheme =3D=3D dr_aligned) 8700 ; 8701 else 8702 TREE_TYPE (data_ref) 8703 =3D build_aligned_type (TREE_TYPE (data_ref), 8704 align * BITS_PER_UNIT); while the incorrect one is (gdb) p debug (dr_info->dr) #(Data Ref:=20 # bb: 51=20 # stmt: a[j_38][k_63] =3D _33; # ref: a[j_38][k_41]; # base_object: a; # Access function 0: {0, +, 1}_3 # Access function 1: j_38 #) $37 =3D void (gdb) p *dr_info $38 =3D {dr =3D 0x3a1be60, stmt =3D 0x3a21f20, group =3D 21, misalignment = =3D 0, target_alignment =3D {> =3D {coeffs =3D {32}= }, },=20 base_misaligned =3D false, base_decl =3D , off= set =3D } (gdb) p *dr_info->dr $39 =3D {stmt =3D , ref =3D , aux =3D 0x0, is_read =3D false, is_conditional_in_stmt =3D false, alias =3D= {ptr_info =3D 0x0}, innermost =3D { base_address =3D , offset =3D , init =3D , step =3D , base_alignment =3D 16,=20 base_misalignment =3D 0, offset_alignment =3D 32, step_alignment =3D 4}= , indices =3D {base_object =3D , access_fns =3D {m_vec =3D 0x= 383ebb0 =3D {0x7fffea058618,=20 0x7fffea03fdc8}}, unconstrained_base =3D false}, alt_indices =3D {base_object =3D , access_fns =3D {m_vec =3D 0x0}, unconstrained_= base =3D false}} base_alignment in both cases is 16, so I wonder why it would think that V8SFmode access on it is aligned. Ah, the first case is actually with V16SFmode access, perhaps something considers just the offset_alignment which is good enough for 32-byte alignm= ent but not 64-byte alignment and disregards base_alignment?=