public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/114566] [11/12/13 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4 Date: Sun, 21 Apr 2024 04:08:59 +0000 [thread overview] Message-ID: <bug-114566-4-gWBWFNzSRw@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 #18 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-13 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:38af0d59043da4cc07cd62c17da599e43668e3be commit r13-8628-g38af0d59043da4cc07cd62c17da599e43668e3be Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Apr 5 14:56:14 2024 +0200 vect: Don't clear base_misaligned in update_epilogue_loop_vinfo [PR114566] The following testcase is miscompiled, because in the vectorized epilogue the vectorizer assumes it can use aligned loads/stores (if the base decl gets alignment increased), but it actually doesn't increase that. This is because r10-4203-g97c1460367 added the hunk following patch removes. The explanation feels reasonable, but actually it is not true as the testcase proves. The thing is, we vectorize the main loop with 64-byte vectors and the corresponding data refs have base_alignment 16 (the a array has DECL_ALIGN 128) and offset_alignment 32. Now, because of the offset_alignment 32 rather than 64, we need to use unaligned loads/stores in the main loop (and ditto in the first load/store in vectorized epilogue). But the second load/store in the vectorized epilogue uses only 32-byte vectors and because it is a multiple of offset_alignment, it checks if we could increase alignment of the a VAR_DECL, the function returns true, sets base_misaligned = true and says the access is then aligned. But when update_epilogue_loop_vinfo clears base_misaligned with the assumption that the var had to have the alignment increased already, the update of DECL_ALIGN doesn't happen anymore. Now, I'd think this base_alignment = false was needed before r10-4030-gd2db7f7901 change was committed where it incorrectly overwrote DECL_ALIGN even if it was already larger, rather than just always increasing it. But with that change in, it doesn't make sense to me anymore. Note, the testcase is latent on the trunk, but reproduces on the 13 branch. 2024-04-05 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/114566 * tree-vect-loop.cc (update_epilogue_loop_vinfo): Don't clear base_misaligned. * gcc.target/i386/avx512f-pr114566.c: New test. (cherry picked from commit a844095e17c1a5aada1364c6f6eaade87ead463c)
next prev parent reply other threads:[~2024-04-21 4:09 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 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 [this message] 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-gWBWFNzSRw@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).