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)

  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: link
Be 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).