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 middle-end/105874] [13 Regression] Incorrect codegen and ICE since g:ed6fd2aed58f2cca99f15331bf68999c0e6df370
Date: Wed, 08 Jun 2022 19:44:24 +0000	[thread overview]
Message-ID: <bug-105874-4-qlPp1UhxYz@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-105874-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:b6e1373bd34aebbb512a03ea9a4e3c7acd955382

commit r13-1016-gb6e1373bd34aebbb512a03ea9a4e3c7acd955382
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Wed Jun 8 20:43:03 2022 +0100

    PR middle-end/105874: Use EXPAND_MEMORY to fix ada bootstrap.

    Many thanks to Tamar Christina for filing PR middle-end/105874 indicating
    that SPECcpu 2017's Leela is failing on x86_64 due to a miscompilation
    of FastBoard::is_eye.  This function is much smaller and easier to work
    with than my previous hunt for the cause of the Ada bootstrap failures
    due to miscompilation somewhere in GCC (or one of the 131 places that
    the problematic form of optimization triggers during an ada bootstrap).

    It turns out the source of the miscompilation introduced by my recent
    patch is the distinction (during RTL expansion) of l-values and r-values.
    According to the documentation above expand_modifier, EXPAND_MEMORY
    should be used for lvalues (when a memory is required), and EXPAND_NORMAL
    for rvalues when a constant is permissible.  In what I'd like to consider
    a latent bug, the recursive call to expand_expr_real on line 11188 of
    expr.cc, in the case handling ARRAY_REF, COMPONENT_REF, BIT_FIELD_REF
    and ARRARY_RANGE_REF was passing EXPAND_NORMAL when it really required
    (the semantics of) EXPAND_MEMORY.  All the time that VAR_DECLs were
    being returned as memory this was fine, but as soon as we're able to
    optimize sort arrays into immediate constants, bad things happen.

    In the test case from Leela, we notice that the array s_eyemask
    always has DImode constant value { 4, 64 }, which is useful as
    an rvalue, but not when we need to index it as an lvalue, as in
    s_eyemask[color].  This also explains why everything being accepted
    by immediate_const_ctor_p (during an ada bootstrap) looks reasonable,
    what's incorrect is that we don't know how these structs/arrays are
    to be used.

    The fix is to ensure that we call expand_expr with EXPAND_MEMORY
    when processing the VAR_DECL's returned by get_inner_reference.

    2022-06-08  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            PR middle-end/105874
            * expr.cc (expand_expr_real_1) <normal_inner_ref>:  New local
            variable tem_modifier for calculating the expand_modifier enum to
            use for expanding tem.  If tem is a VAR_DECL, use EXPAND_MEMORY.

    gcc/testsuite/ChangeLog
            PR middle-end/105874
            * g++.dg/opt/pr105874.C: New test case.

  parent reply	other threads:[~2022-06-08 19:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-07 14:45 [Bug middle-end/105874] New: " tnfchris at gcc dot gnu.org
2022-06-07 17:58 ` [Bug middle-end/105874] " roger at nextmovesoftware dot com
2022-06-07 19:14 ` roger at nextmovesoftware dot com
2022-06-08  9:20 ` tnfchris at gcc dot gnu.org
2022-06-08 13:08 ` roger at nextmovesoftware dot com
2022-06-08 15:42 ` tnfchris at gcc dot gnu.org
2022-06-08 19:43 ` ebotcazou at gcc dot gnu.org
2022-06-08 19:44 ` cvs-commit at gcc dot gnu.org [this message]
2022-06-09  7:45 ` tnfchris at gcc dot gnu.org
2022-06-09 11:05 ` roger at nextmovesoftware dot com
2022-07-01  8:01 ` 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-105874-4-qlPp1UhxYz@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).