public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
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 16:33:39 +0000 [thread overview] Message-ID: <bug-114566-4-XdYLhBgSPC@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114566-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- The user align:32 MEM_REF comes from (gdb) p debug (dr_info->dr) #(Data Ref: # bb: 21 # stmt: a[j_38][k_41] = _48; # ref: a[j_38][k_41]; # base_object: a; # Access function 0: {0, +, 1}_3 # Access function 1: j_38 #) $34 = void (gdb) p *dr_info $35 = {dr = 0x3a1be60, stmt = 0x3a1ef10, group = 21, misalignment = -1, target_alignment = {<poly_int_pod<1, unsigned long>> = {coeffs = {64}}, <No data fields>}, base_misaligned = false, base_decl = <tree 0x0>, offset = <tree 0x0>} (gdb) p *dr_info->dr $36 = {stmt = <gimple_assign 0x7fffea04e320>, ref = <array_ref 0x7fffea139bd0>, aux = 0x0, is_read = false, is_conditional_in_stmt = false, alias = {ptr_info = 0x0}, innermost = { base_address = <addr_expr 0x7fffea051160>, offset = <nop_expr 0x7fffea051180>, init = <integer_cst 0x7fffea0474f8>, step = <integer_cst 0x7fffea047528>, base_alignment = 16, base_misalignment = 0, offset_alignment = 32, step_alignment = 4}, indices = {base_object = <mem_ref 0x7fffea058ac8>, access_fns = {m_vec = 0x383ebb0 = {0x7fffea058618, 0x7fffea03fdc8}}, unconstrained_base = false}, alt_indices = {base_object = <tree 0x0>, access_fns = {m_vec = 0x0}, unconstrained_base = false}} dr in vectorizable_store, alignment_support_scheme is dr_unaligned_supported and so build_aligned_type is done: 8694 data_ref = 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 == dr_aligned) 8700 ; 8701 else 8702 TREE_TYPE (data_ref) 8703 = 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: # bb: 51 # stmt: a[j_38][k_63] = _33; # ref: a[j_38][k_41]; # base_object: a; # Access function 0: {0, +, 1}_3 # Access function 1: j_38 #) $37 = void (gdb) p *dr_info $38 = {dr = 0x3a1be60, stmt = 0x3a21f20, group = 21, misalignment = 0, target_alignment = {<poly_int_pod<1, unsigned long>> = {coeffs = {32}}, <No data fields>}, base_misaligned = false, base_decl = <var_decl 0x7fffea13bcf0 a>, offset = <integer_cst 0x7fffea0477e0>} (gdb) p *dr_info->dr $39 = {stmt = <gimple_assign 0x7fffea04e9b0>, ref = <array_ref 0x7fffea139bd0>, aux = 0x0, is_read = false, is_conditional_in_stmt = false, alias = {ptr_info = 0x0}, innermost = { base_address = <addr_expr 0x7fffea051160>, offset = <nop_expr 0x7fffea051180>, init = <integer_cst 0x7fffea0474f8>, step = <integer_cst 0x7fffea047528>, base_alignment = 16, base_misalignment = 0, offset_alignment = 32, step_alignment = 4}, indices = {base_object = <mem_ref 0x7fffea058ac8>, access_fns = {m_vec = 0x383ebb0 = {0x7fffea058618, 0x7fffea03fdc8}}, unconstrained_base = false}, alt_indices = {base_object = <tree 0x0>, access_fns = {m_vec = 0x0}, unconstrained_base = 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 alignment but not 64-byte alignment and disregards base_alignment?
next prev parent reply other threads:[~2024-04-04 16:33 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-04-02 18:19 [Bug c/114566] New: Misaligned vmovaps when compiling libvorbis " yshuiv7 at gmail dot com 2024-04-02 18:28 ` [Bug target/114566] " pinskia at gcc dot gnu.org 2024-04-02 19:33 ` yshuiv7 at gmail dot com 2024-04-02 20:15 ` yshuiv7 at gmail dot com 2024-04-02 20:22 ` yshuiv7 at gmail dot com 2024-04-02 20:28 ` yshuiv7 at gmail dot com 2024-04-02 20:37 ` pinskia at gcc dot gnu.org 2024-04-02 20:40 ` yshuiv7 at gmail dot com 2024-04-02 20:44 ` [Bug target/114566] Misaligned vmovaps when compiling with stack-protector-strong " pinskia at gcc dot gnu.org 2024-04-04 15:22 ` jakub at gcc dot gnu.org 2024-04-04 15:23 ` [Bug target/114566] [11/12/13 Regression] " jakub at gcc dot gnu.org 2024-04-04 15:40 ` jakub at gcc dot gnu.org 2024-04-04 15:46 ` jakub at gcc dot gnu.org 2024-04-04 16:33 ` jakub at gcc dot gnu.org [this message] 2024-04-04 16:57 ` jakub at gcc dot gnu.org 2024-04-04 17:08 ` [Bug target/114566] [11/12/13/14 " jakub at gcc dot gnu.org 2024-04-04 17:14 ` pinskia at gcc dot gnu.org 2024-04-05 10:30 ` [Bug tree-optimization/114566] " jakub at gcc dot gnu.org 2024-04-05 12:56 ` cvs-commit at gcc dot gnu.org 2024-04-05 12:57 ` [Bug tree-optimization/114566] [11/12/13 " jakub at gcc dot gnu.org 2024-04-21 4:08 ` cvs-commit at gcc dot gnu.org 2024-04-23 6:45 ` [Bug tree-optimization/114566] [11/12 " jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-114566-4-XdYLhBgSPC@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).