public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tnfchris at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled Date: Mon, 29 Jan 2024 18:09:35 +0000 [thread overview] Message-ID: <bug-113467-4-ycpyHZ4XzT@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-113467-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467 Tamar Christina <tnfchris at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2024-01-29 Ever confirmed|0 |1 --- Comment #27 from Tamar Christina <tnfchris at gcc dot gnu.org> --- So this loop shouldn't have been vectorized. It is indeed a dup of the same problem as in PR113588. The issue is that this loop contains a memory access to an unknown sized array in the BB containing the loop CFG latch. My initial patch here analyzed all loads but during review we thought that was too restrictive, that we only need to analyze the loads in blocks which contain an early exit and the loads reachable from the COND in the destination block. The reasoning was that if you were to pass all the early exits the loads in the final block would only be reached if you didn't take the exit. This is then the same as normal vectorization and the loads are safe to issue after the bounds check. What it doesn't take into account is that if you pick a different exit the latch then shifts as we discussed before. The reason Richi's change worked before is that it forced the loop back upright which then made the analysis correctly block it. The bug is a sneaky one, but essentially vect_analyze_data_ref_dependence needs to also keep in mind which exit is the main exit as determined by vec_init_loop_exit_info. In other words, it needs to use the vectorizer's chosen exit and not the loop infrastructure. Mine.
next prev parent reply other threads:[~2024-01-29 18:09 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-01-18 5:21 [Bug tree-optimization/113467] New: " sjames at gcc dot gnu.org 2024-01-18 5:22 ` [Bug tree-optimization/113467] " sjames at gcc dot gnu.org 2024-01-18 5:23 ` sjames at gcc dot gnu.org 2024-01-18 5:23 ` sjames at gcc dot gnu.org 2024-01-18 5:24 ` sjames at gcc dot gnu.org 2024-01-18 5:46 ` sjames at gcc dot gnu.org 2024-01-18 6:53 ` sjames at gcc dot gnu.org 2024-01-18 8:22 ` rguenth at gcc dot gnu.org 2024-01-18 8:49 ` rguenth at gcc dot gnu.org 2024-01-18 8:51 ` rguenth at gcc dot gnu.org 2024-01-18 9:32 ` sjames at gcc dot gnu.org 2024-01-18 9:35 ` sjames at gcc dot gnu.org 2024-01-18 13:16 ` rguenth at gcc dot gnu.org 2024-01-18 16:47 ` sjames at gcc dot gnu.org 2024-01-19 2:31 ` sjames at gcc dot gnu.org 2024-01-19 3:00 ` sjames at gcc dot gnu.org 2024-01-19 7:06 ` rguenth at gcc dot gnu.org 2024-01-19 11:36 ` jakub at gcc dot gnu.org 2024-01-19 13:37 ` rguenth at gcc dot gnu.org 2024-01-23 16:11 ` sjames at gcc dot gnu.org 2024-01-23 17:06 ` tnfchris at gcc dot gnu.org 2024-01-23 17:42 ` rguenther at suse dot de 2024-01-23 17:47 ` tnfchris at gcc dot gnu.org 2024-01-24 7:32 ` rguenth at gcc dot gnu.org 2024-01-26 13:28 ` rguenth at gcc dot gnu.org 2024-01-26 13:33 ` sjames at gcc dot gnu.org 2024-01-26 13:44 ` sjames at gcc dot gnu.org 2024-01-26 14:04 ` tnfchris at gcc dot gnu.org 2024-01-26 19:45 ` kacper.slominski72 at gmail dot com 2024-01-29 18:09 ` tnfchris at gcc dot gnu.org [this message] 2024-01-30 8:01 ` sjames at gcc dot gnu.org 2024-02-01 21:56 ` sjames at gcc dot gnu.org 2024-02-02 23:56 ` cvs-commit at gcc dot gnu.org 2024-02-03 22:03 ` sjames at gcc dot gnu.org 2024-02-07 10:57 ` cvs-commit 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-113467-4-ycpyHZ4XzT@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).