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 middle-end/105874] New: [13 Regression] Incorrect codegen and ICE since g:ed6fd2aed58f2cca99f15331bf68999c0e6df370
Date: Tue, 07 Jun 2022 14:45:40 +0000	[thread overview]
Message-ID: <bug-105874-4@http.gcc.gnu.org/bugzilla/> (raw)

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

            Bug ID: 105874
           Summary: [13 Regression] Incorrect codegen and ICE since
                    g:ed6fd2aed58f2cca99f15331bf68999c0e6df370
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code, wrong-code
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tnfchris at gcc dot gnu.org
                CC: sayle at gcc dot gnu.org
  Target Milestone: ---
            Target: aarch64*

In SPECCPU 2017 Leela no longer terminates since
g:ed6fd2aed58f2cca99f15331bf68999c0e6df370

Looking at the differences in the code, there seems to be a lot of additional
useless calculation around functions such as _ZN9FastBoard6is_eyeEii

Filtering through them it looks like the change is causing loads from
uninitialize d stack space.

Before the change the code generated

```
_ZN9FastBoard6is_eyeEii:
adrp    x3, <<diffable>>
mov     x4, #0x1ba4                     // #7076
add     x4, x0, x4
add     x3, x3, #0xb20
ldrh    w4, [x4, w2, sxtw #1]
ldr     w3, [x3, w1, sxtw #2]
tst     w4, w3
```

So it loaded from a fixed anchor into rdata.  After the change

```
_ZN9FastBoard6is_eyeEii:
sub     sp, sp, #0x20
mov     x4, #0x1ba4
add     x5, x0, x4
add     x4, sp, #0x8
ldrh    w5, [x5, w2, sxtw #1]
ldr     w4, [x4, w1, sxtw #2]
tst     w5, w4
```

So it allocated 32 bytes of stack and then decides to load from uninitialized
space at sp+0x8.

I tried to create a minimal reproducer but the compiler ICEs as you get close.
e.g. even the example from the ticket PR95126

struct small{ short a,b; signed char c; };
extern int func(struct small X);
void call_func(void)
{
    static struct small const s = { 1, 2, 0 };
    func(s);
}

ICEs at -O2 with:

during RTL pass: expand
../borked.c: In function 'call_func':
../borked.c:6:5: internal compiler error: in emit_move_insn, at expr.cc:4011
    6 |     func(s);
      |     ^~~~~~~
0x909253 emit_move_insn(rtx_def*, rtx_def*)
        /ci/work/5c94c4ced6ebfcd0/gcc/expr.cc:4011
0x7eda3f load_register_parameters
        /ci/work/5c94c4ced6ebfcd0/gcc/calls.cc:2192
0x7f2183 expand_call(tree_node*, rtx_def*, int)
        /ci/work/5c94c4ced6ebfcd0/gcc/calls.cc:3593
0x905ccb expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        /ci/work/5c94c4ced6ebfcd0/gcc/expr.cc:11621
0x8057e3 expand_expr
        /ci/work/5c94c4ced6ebfcd0/gcc/expr.h:301
0x8057e3 expand_call_stmt
        /ci/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:2831
0x8057e3 expand_gimple_stmt_1
        /ci/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:3869
0x8057e3 expand_gimple_stmt
        /ci/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:4033
0x80a44b expand_gimple_tailcall
        /ci/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:4079
0x80a44b expand_gimple_basic_block
        /ci/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:6059
0x80cbbf execute
        /ci/work/5c94c4ced6ebfcd0/gcc/cfgexpand.cc:6811

So I can't really reduce it at this point.

             reply	other threads:[~2022-06-07 14:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-07 14:45 tnfchris at gcc dot gnu.org [this message]
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
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@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).