public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59
@ 2022-02-08 19:40 gscfq@t-online.de
  2022-02-08 21:37 ` [Bug middle-end/104446] " pinskia at gcc dot gnu.org
                   ` (12 more replies)
  0 siblings, 13 replies; 14+ messages in thread
From: gscfq@t-online.de @ 2022-02-08 19:40 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 104446
           Summary: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at
                    explow.cc:59
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

With file ./gcc.target/i386/pr65588.c :


$ gcc-12-20220206 -c pr65588.c -O2 -m32 -mrtd -finstrument-functions
during RTL pass: combine
pr65588.c: In function 't':
pr65588.c:10:19: internal compiler error: in trunc_int_for_mode, at
explow.cc:59
   10 | int t () { a = 0; }
      |                   ^
0x8b5d13 trunc_int_for_mode(long, machine_mode)
        ../../gcc/explow.cc:59
0x8b5d28 trunc_int_for_mode(poly_int<1u, long>, machine_mode)
        ../../gcc/explow.cc:86
0x8aa928 gen_int_mode(poly_int<1u, long>, machine_mode)
        ../../gcc/emit-rtl.cc:542
0xbc3d78 for_each_inc_dec_find_inc_dec
        ../../gcc/rtlanal.cc:3711
0xbc3d78 for_each_inc_dec(rtx_def*, int (*)(rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, void*), void*)
        ../../gcc/rtlanal.cc:3750
0x17597af try_combine
        ../../gcc/combine.cc:3346
0x175f3cc combine_instructions
        ../../gcc/combine.cc:1269
0x175f3cc rest_of_handle_combine
        ../../gcc/combine.cc:14922
0x175f3cc execute
        ../../gcc/combine.cc:14967

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
@ 2022-02-08 21:37 ` pinskia at gcc dot gnu.org
  2022-02-09  7:32 ` rguenth at gcc dot gnu.org
                   ` (11 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-02-08 21:37 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-bisection
      Known to fail|                            |11.2.0, 9.1.0
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-02-08
      Known to work|                            |8.1.0
   Target Milestone|---                         |9.5
     Ever confirmed|0                           |1
          Component|c                           |middle-end

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed reduced testcase w/o -finstrument-functions:
That is only -O2 -m32 -mrtd is needed to produce the ICE.

register volatile int a __asm__("%esp");

void f(void*);
void f1(void*);

void t ()
{
    f(__builtin_return_address(0));
    a = 0;
    f1(__builtin_return_address(0));
}

---- CUT ---
Note this works with the C++ front-end for some reason.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
  2022-02-08 21:37 ` [Bug middle-end/104446] " pinskia at gcc dot gnu.org
@ 2022-02-09  7:32 ` rguenth at gcc dot gnu.org
  2022-02-09  9:04 ` [Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999 jakub at gcc dot gnu.org
                   ` (10 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-02-09  7:32 UTC (permalink / raw)
  To: gcc-bugs

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
  2022-02-08 21:37 ` [Bug middle-end/104446] " pinskia at gcc dot gnu.org
  2022-02-09  7:32 ` rguenth at gcc dot gnu.org
@ 2022-02-09  9:04 ` jakub at gcc dot gnu.org
  2022-02-09 11:13 ` jakub at gcc dot gnu.org
                   ` (9 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-09  9:04 UTC (permalink / raw)
  To: gcc-bugs

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE
                   |in trunc_int_for_mode, at   |in trunc_int_for_mode, at
                   |explow.cc:59                |explow.cc:59 since r9-6999
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r9-6999-gc7797fd3e8889f7017980672dad06a3df8f4cddf

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
                   ` (2 preceding siblings ...)
  2022-02-09  9:04 ` [Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999 jakub at gcc dot gnu.org
@ 2022-02-09 11:13 ` jakub at gcc dot gnu.org
  2022-02-09 11:32 ` jakub at gcc dot gnu.org
                   ` (8 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-09 11:13 UTC (permalink / raw)
  To: gcc-bugs

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |segher at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is that combine substutites:
(insn 10 9 11 2 (set (reg/v:SI 7 sp [ a ])
        (const_int 0 [0])) "pr104446.c":9:5 81 {*movsi_internal}
     (nil))
(insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [0  S4 A32])
        (reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
     (expr_list:REG_DEAD (reg:SI 85)
        (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
            (nil))))
into:
(mem/f:SI (pre_dec:SI (const_int 0 [0])) [0  S4 A32])
and before it is attempted to be recognized, we do:
3347          for_each_inc_dec (newpat, count_auto_inc, &new_n_auto_inc);
and that ICEs because:
3709            poly_int64 size = GET_MODE_SIZE (GET_MODE (mem));
3710            rtx r1 = XEXP (x, 0);
3711            rtx c = gen_int_mode (-size, GET_MODE (r1));
3712            return fn (mem, x, r1, r1, c, data);
gen_int_mode (-4, VOIDmode) is invalid.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
                   ` (3 preceding siblings ...)
  2022-02-09 11:13 ` jakub at gcc dot gnu.org
@ 2022-02-09 11:32 ` jakub at gcc dot gnu.org
  2022-02-10  7:47 ` segher at gcc dot gnu.org
                   ` (7 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-09 11:32 UTC (permalink / raw)
  To: gcc-bugs

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52385&action=edit
gcc12-pr104446.patch

Untested fix.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
                   ` (4 preceding siblings ...)
  2022-02-09 11:32 ` jakub at gcc dot gnu.org
@ 2022-02-10  7:47 ` segher at gcc dot gnu.org
  2022-02-11 12:52 ` cvs-commit at gcc dot gnu.org
                   ` (6 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: segher at gcc dot gnu.org @ 2022-02-10  7:47 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
This testcase is invalid code of course, so anything can happen.  ICEs are bad
though ;-)

Please add to the comment that you don't want this substitution because it
leads
to ICEs, and mention the PR # in the comment.  But better, figure out *why*
this
ICEs later on: it is perfectly normal for combine to create RTL that is
non-sensical but structurally correct, and it should simply not pass recog.
This patch avoids the problem, and does not fix it.  It would be good to know
what the real problem is.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
                   ` (5 preceding siblings ...)
  2022-02-10  7:47 ` segher at gcc dot gnu.org
@ 2022-02-11 12:52 ` cvs-commit at gcc dot gnu.org
  2022-02-11 12:53 ` [Bug middle-end/104446] [9/10/11 " jakub at gcc dot gnu.org
                   ` (5 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-11 12:52 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

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

commit r12-7196-gfb76c0ad35f96505ecd9213849ebc3df6163a0f7
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Feb 11 11:34:46 2022 +0100

    combine: Fix ICE with substitution of CONST_INT into PRE_DEC argument
[PR104446]

    The following testcase ICEs, because combine substitutes
    (insn 10 9 11 2 (set (reg/v:SI 7 sp [ a ])
            (const_int 0 [0])) "pr104446.c":9:5 81 {*movsi_internal}
         (nil))
    (insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [0  S4 A32])
            (reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
         (expr_list:REG_DEAD (reg:SI 85)
            (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
                (nil))))
    forming
    (insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (const_int 0 [0])) [0  S4 A32])
            (reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
         (expr_list:REG_DEAD (reg:SI 85)
            (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
                (nil))))
    which is invalid RTL (pre_dec's argument must be a REG).
    I know substitution creates various forms of invalid RTL and hopes that
    invalid RTL just won't recog.
    But unfortunately in this case we ICE before we get to recog, as
    try_combine does:
      if (n_auto_inc)
        {
          int new_n_auto_inc = 0;
          for_each_inc_dec (newpat, count_auto_inc, &new_n_auto_inc);

          if (n_auto_inc != new_n_auto_inc)
            {
              if (dump_file && (dump_flags & TDF_DETAILS))
                fprintf (dump_file, "Number of auto_inc expressions
changed\n");
              undo_all ();
              return 0;
            }
        }
    and for_each_inc_dec under the hood will do e.g. for the PRE_DEC case:
        case PRE_DEC:
        case POST_DEC:
          {
            poly_int64 size = GET_MODE_SIZE (GET_MODE (mem));
            rtx r1 = XEXP (x, 0);
            rtx c = gen_int_mode (-size, GET_MODE (r1));
            return fn (mem, x, r1, r1, c, data);
          }
    and that code rightfully expects that the PRE_DEC operand has non-VOIDmode
    (as it needs to be a REG) - gen_int_mode for VOIDmode results in ICE.
    I think it is better not to emit the clearly invalid RTL during
substitution
    like we do for other cases, than to adding workarounds for invalid IL
    created by combine to rtlanal.cc and perhaps elsewhere.
    As for the testcase, of course it is UB at runtime to modify sp that way,
    but if such code is never reached, we must compile it, not to ICE on it.
    And I don't see why on other targets which use the autoinc rtxes much more
    it couldn't happen with other registers.

    2022-02-11  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/104446
            * combine.cc (subst): Don't substitute CONST_INTs into RTX_AUTOINC
            operands.

            * gcc.target/i386/pr104446.c: New test.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10/11 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
                   ` (6 preceding siblings ...)
  2022-02-11 12:52 ` cvs-commit at gcc dot gnu.org
@ 2022-02-11 12:53 ` jakub at gcc dot gnu.org
  2022-02-19  8:02 ` cvs-commit at gcc dot gnu.org
                   ` (4 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-11 12:53 UTC (permalink / raw)
  To: gcc-bugs

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE in
                   |in trunc_int_for_mode, at   |trunc_int_for_mode, at
                   |explow.cc:59 since r9-6999  |explow.cc:59 since r9-6999

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10/11 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
                   ` (7 preceding siblings ...)
  2022-02-11 12:53 ` [Bug middle-end/104446] [9/10/11 " jakub at gcc dot gnu.org
@ 2022-02-19  8:02 ` cvs-commit at gcc dot gnu.org
  2022-02-19  8:08 ` [Bug middle-end/104446] [9/10 " jakub at gcc dot gnu.org
                   ` (3 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-19  8:02 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:25de6af07994e57626a16a91fa5d3944ba8ddcde

commit r11-9601-g25de6af07994e57626a16a91fa5d3944ba8ddcde
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Feb 11 11:34:46 2022 +0100

    combine: Fix ICE with substitution of CONST_INT into PRE_DEC argument
[PR104446]

    The following testcase ICEs, because combine substitutes
    (insn 10 9 11 2 (set (reg/v:SI 7 sp [ a ])
            (const_int 0 [0])) "pr104446.c":9:5 81 {*movsi_internal}
         (nil))
    (insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [0  S4 A32])
            (reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
         (expr_list:REG_DEAD (reg:SI 85)
            (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
                (nil))))
    forming
    (insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (const_int 0 [0])) [0  S4 A32])
            (reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
         (expr_list:REG_DEAD (reg:SI 85)
            (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
                (nil))))
    which is invalid RTL (pre_dec's argument must be a REG).
    I know substitution creates various forms of invalid RTL and hopes that
    invalid RTL just won't recog.
    But unfortunately in this case we ICE before we get to recog, as
    try_combine does:
      if (n_auto_inc)
        {
          int new_n_auto_inc = 0;
          for_each_inc_dec (newpat, count_auto_inc, &new_n_auto_inc);

          if (n_auto_inc != new_n_auto_inc)
            {
              if (dump_file && (dump_flags & TDF_DETAILS))
                fprintf (dump_file, "Number of auto_inc expressions
changed\n");
              undo_all ();
              return 0;
            }
        }
    and for_each_inc_dec under the hood will do e.g. for the PRE_DEC case:
        case PRE_DEC:
        case POST_DEC:
          {
            poly_int64 size = GET_MODE_SIZE (GET_MODE (mem));
            rtx r1 = XEXP (x, 0);
            rtx c = gen_int_mode (-size, GET_MODE (r1));
            return fn (mem, x, r1, r1, c, data);
          }
    and that code rightfully expects that the PRE_DEC operand has non-VOIDmode
    (as it needs to be a REG) - gen_int_mode for VOIDmode results in ICE.
    I think it is better not to emit the clearly invalid RTL during
substitution
    like we do for other cases, than to adding workarounds for invalid IL
    created by combine to rtlanal.cc and perhaps elsewhere.
    As for the testcase, of course it is UB at runtime to modify sp that way,
    but if such code is never reached, we must compile it, not to ICE on it.
    And I don't see why on other targets which use the autoinc rtxes much more
    it couldn't happen with other registers.

    2022-02-11  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/104446
            * combine.c (subst): Don't substitute CONST_INTs into RTX_AUTOINC
            operands.

            * gcc.target/i386/pr104446.c: New test.

    (cherry picked from commit fb76c0ad35f96505ecd9213849ebc3df6163a0f7)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10 Regression] ICE in trunc_int_for_mode,  at explow.cc:59 since r9-6999
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
                   ` (8 preceding siblings ...)
  2022-02-19  8:02 ` cvs-commit at gcc dot gnu.org
@ 2022-02-19  8:08 ` jakub at gcc dot gnu.org
  2022-05-10  8:23 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-19  8:08 UTC (permalink / raw)
  To: gcc-bugs

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
                   |trunc_int_for_mode, at      |trunc_int_for_mode, at
                   |explow.cc:59 since r9-6999  |explow.cc:59 since r9-6999

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.3+ too.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10 Regression] ICE in trunc_int_for_mode,  at explow.cc:59 since r9-6999
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
                   ` (9 preceding siblings ...)
  2022-02-19  8:08 ` [Bug middle-end/104446] [9/10 " jakub at gcc dot gnu.org
@ 2022-05-10  8:23 ` cvs-commit at gcc dot gnu.org
  2022-05-11  6:24 ` cvs-commit at gcc dot gnu.org
  2022-05-11  6:36 ` jakub at gcc dot gnu.org
  12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-10  8:23 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:2ae27346fb5909fb6284f65bec55bcec83533d1e

commit r10-10676-g2ae27346fb5909fb6284f65bec55bcec83533d1e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Feb 11 11:34:46 2022 +0100

    combine: Fix ICE with substitution of CONST_INT into PRE_DEC argument
[PR104446]

    The following testcase ICEs, because combine substitutes
    (insn 10 9 11 2 (set (reg/v:SI 7 sp [ a ])
            (const_int 0 [0])) "pr104446.c":9:5 81 {*movsi_internal}
         (nil))
    (insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [0  S4 A32])
            (reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
         (expr_list:REG_DEAD (reg:SI 85)
            (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
                (nil))))
    forming
    (insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (const_int 0 [0])) [0  S4 A32])
            (reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
         (expr_list:REG_DEAD (reg:SI 85)
            (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
                (nil))))
    which is invalid RTL (pre_dec's argument must be a REG).
    I know substitution creates various forms of invalid RTL and hopes that
    invalid RTL just won't recog.
    But unfortunately in this case we ICE before we get to recog, as
    try_combine does:
      if (n_auto_inc)
        {
          int new_n_auto_inc = 0;
          for_each_inc_dec (newpat, count_auto_inc, &new_n_auto_inc);

          if (n_auto_inc != new_n_auto_inc)
            {
              if (dump_file && (dump_flags & TDF_DETAILS))
                fprintf (dump_file, "Number of auto_inc expressions
changed\n");
              undo_all ();
              return 0;
            }
        }
    and for_each_inc_dec under the hood will do e.g. for the PRE_DEC case:
        case PRE_DEC:
        case POST_DEC:
          {
            poly_int64 size = GET_MODE_SIZE (GET_MODE (mem));
            rtx r1 = XEXP (x, 0);
            rtx c = gen_int_mode (-size, GET_MODE (r1));
            return fn (mem, x, r1, r1, c, data);
          }
    and that code rightfully expects that the PRE_DEC operand has non-VOIDmode
    (as it needs to be a REG) - gen_int_mode for VOIDmode results in ICE.
    I think it is better not to emit the clearly invalid RTL during
substitution
    like we do for other cases, than to adding workarounds for invalid IL
    created by combine to rtlanal.cc and perhaps elsewhere.
    As for the testcase, of course it is UB at runtime to modify sp that way,
    but if such code is never reached, we must compile it, not to ICE on it.
    And I don't see why on other targets which use the autoinc rtxes much more
    it couldn't happen with other registers.

    2022-02-11  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/104446
            * combine.c (subst): Don't substitute CONST_INTs into RTX_AUTOINC
            operands.

            * gcc.target/i386/pr104446.c: New test.

    (cherry picked from commit fb76c0ad35f96505ecd9213849ebc3df6163a0f7)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10 Regression] ICE in trunc_int_for_mode,  at explow.cc:59 since r9-6999
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
                   ` (10 preceding siblings ...)
  2022-05-10  8:23 ` cvs-commit at gcc dot gnu.org
@ 2022-05-11  6:24 ` cvs-commit at gcc dot gnu.org
  2022-05-11  6:36 ` jakub at gcc dot gnu.org
  12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-11  6:24 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

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

commit r9-10124-gffbe41f14f416dd0660108d78ee550256bdca7ea
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Feb 11 11:34:46 2022 +0100

    combine: Fix ICE with substitution of CONST_INT into PRE_DEC argument
[PR104446]

    The following testcase ICEs, because combine substitutes
    (insn 10 9 11 2 (set (reg/v:SI 7 sp [ a ])
            (const_int 0 [0])) "pr104446.c":9:5 81 {*movsi_internal}
         (nil))
    (insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [0  S4 A32])
            (reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
         (expr_list:REG_DEAD (reg:SI 85)
            (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
                (nil))))
    forming
    (insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (const_int 0 [0])) [0  S4 A32])
            (reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
         (expr_list:REG_DEAD (reg:SI 85)
            (expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
                (nil))))
    which is invalid RTL (pre_dec's argument must be a REG).
    I know substitution creates various forms of invalid RTL and hopes that
    invalid RTL just won't recog.
    But unfortunately in this case we ICE before we get to recog, as
    try_combine does:
      if (n_auto_inc)
        {
          int new_n_auto_inc = 0;
          for_each_inc_dec (newpat, count_auto_inc, &new_n_auto_inc);

          if (n_auto_inc != new_n_auto_inc)
            {
              if (dump_file && (dump_flags & TDF_DETAILS))
                fprintf (dump_file, "Number of auto_inc expressions
changed\n");
              undo_all ();
              return 0;
            }
        }
    and for_each_inc_dec under the hood will do e.g. for the PRE_DEC case:
        case PRE_DEC:
        case POST_DEC:
          {
            poly_int64 size = GET_MODE_SIZE (GET_MODE (mem));
            rtx r1 = XEXP (x, 0);
            rtx c = gen_int_mode (-size, GET_MODE (r1));
            return fn (mem, x, r1, r1, c, data);
          }
    and that code rightfully expects that the PRE_DEC operand has non-VOIDmode
    (as it needs to be a REG) - gen_int_mode for VOIDmode results in ICE.
    I think it is better not to emit the clearly invalid RTL during
substitution
    like we do for other cases, than to adding workarounds for invalid IL
    created by combine to rtlanal.cc and perhaps elsewhere.
    As for the testcase, of course it is UB at runtime to modify sp that way,
    but if such code is never reached, we must compile it, not to ICE on it.
    And I don't see why on other targets which use the autoinc rtxes much more
    it couldn't happen with other registers.

    2022-02-11  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/104446
            * combine.c (subst): Don't substitute CONST_INTs into RTX_AUTOINC
            operands.

            * gcc.target/i386/pr104446.c: New test.

    (cherry picked from commit fb76c0ad35f96505ecd9213849ebc3df6163a0f7)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug middle-end/104446] [9/10 Regression] ICE in trunc_int_for_mode,  at explow.cc:59 since r9-6999
  2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
                   ` (11 preceding siblings ...)
  2022-05-11  6:24 ` cvs-commit at gcc dot gnu.org
@ 2022-05-11  6:36 ` jakub at gcc dot gnu.org
  12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-05-11  6:36 UTC (permalink / raw)
  To: gcc-bugs

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2022-05-11  6:36 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-08 19:40 [Bug c/104446] New: [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 gscfq@t-online.de
2022-02-08 21:37 ` [Bug middle-end/104446] " pinskia at gcc dot gnu.org
2022-02-09  7:32 ` rguenth at gcc dot gnu.org
2022-02-09  9:04 ` [Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999 jakub at gcc dot gnu.org
2022-02-09 11:13 ` jakub at gcc dot gnu.org
2022-02-09 11:32 ` jakub at gcc dot gnu.org
2022-02-10  7:47 ` segher at gcc dot gnu.org
2022-02-11 12:52 ` cvs-commit at gcc dot gnu.org
2022-02-11 12:53 ` [Bug middle-end/104446] [9/10/11 " jakub at gcc dot gnu.org
2022-02-19  8:02 ` cvs-commit at gcc dot gnu.org
2022-02-19  8:08 ` [Bug middle-end/104446] [9/10 " jakub at gcc dot gnu.org
2022-05-10  8:23 ` cvs-commit at gcc dot gnu.org
2022-05-11  6:24 ` cvs-commit at gcc dot gnu.org
2022-05-11  6:36 ` jakub at gcc dot gnu.org

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).