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/110702] [12/13 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2) Date: Thu, 24 Aug 2023 10:56:06 +0000 [thread overview] Message-ID: <bug-110702-4-creB2kWZR7@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-110702-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110702 --- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-13 branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:5ca9aea695396266b7eb7d2a065e6f2e9546047e commit r13-7752-g5ca9aea695396266b7eb7d2a065e6f2e9546047e Author: Richard Biener <rguenther@suse.de> Date: Thu Aug 3 13:11:12 2023 +0200 tree-optimization/110702 - avoid zero-based memory references in IVOPTs Sometimes IVOPTs chooses a weird induction variable which downstream leads to issues. Most of the times we can fend those off during costing by rejecting the candidate but it looks like the address description costing synthesizes is different from what we end up generating so the following fixes things up at code generation time. Specifically we avoid the create_mem_ref_raw fallback which uses a literal zero address base with the actual base in index2. For the case in question we have the address type = unsigned long offset = 0 elements = { [0] = &e * -3, [1] = (sizetype) a.9_30 * 232, [2] = ivtmp.28_44 * 4 } from which we code generate the problematical _3 = MEM[(long int *)0B + ivtmp.36_9 + ivtmp.28_44 * 4]; which references the object at address zero. The patch below recognizes the fallback after the fact and transforms the TARGET_MEM_REF memory reference into a LEA for which this form isn't problematic: _24 = &MEM[(long int *)0B + ivtmp.36_34 + ivtmp.28_44 * 4]; _3 = *_24; hereby avoiding the correctness issue. We'd later conclude the program terminates at the null pointer dereference and make the function pure, miscompling the main function of the testcase. PR tree-optimization/110702 * tree-ssa-loop-ivopts.cc (rewrite_use_address): When we created a NULL pointer based access rewrite that to a LEA. * gcc.dg/torture/pr110702.c: New testcase. (cherry picked from commit 13dfb01e5c30c3bd09333ac79d6ff96a617fea67)
next prev parent reply other threads:[~2023-08-24 10:56 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-07-17 13:26 [Bug c/110702] New: " shaohua.li at inf dot ethz.ch 2023-07-17 18:39 ` [Bug c/110702] [12/13/14 Regression] " pinskia at gcc dot gnu.org 2023-07-17 18:45 ` [Bug middle-end/110702] " pinskia at gcc dot gnu.org 2023-07-18 14:09 ` mikpelinux at gmail dot com 2023-07-30 14:57 ` shaohua.li at inf dot ethz.ch 2023-08-03 9:32 ` [Bug tree-optimization/110702] " rguenth at gcc dot gnu.org 2023-08-03 10:59 ` rguenth at gcc dot gnu.org 2023-08-03 12:22 ` cvs-commit at gcc dot gnu.org 2023-08-03 12:23 ` [Bug tree-optimization/110702] [12/13 " rguenth at gcc dot gnu.org 2023-08-24 10:56 ` cvs-commit at gcc dot gnu.org [this message] 2023-09-22 5:46 ` [Bug tree-optimization/110702] [12 " rguenth at gcc dot gnu.org 2023-11-27 11:35 ` cvs-commit at gcc dot gnu.org 2023-11-27 11:37 ` rguenth 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-110702-4-creB2kWZR7@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).