[Bug c/104402] New: ICE on valid code: in do_jump_1, at dojump.c

[Bug c/104402] New: ICE on valid code: in do_jump_1, at dojump.c

[k.even-mendoza at imperial dot ac.uk]

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

            Bug ID: 104402
           Summary: ICE on valid code: in do_jump_1, at dojump.c
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: k.even-mendoza at imperial dot ac.uk
  Target Milestone: ---

ICE started from gcc-9 and still appears in gcc-12 (I tested it with gcc (GCC)
12.0.0 20220116 (experimental)) with this code and -O2:

#include <stdlib.h>
_Complex a;
char b;
void main() {}
void c() {
  if (b != 2 + (long)(a != 0 ^ 0))
    abort();
}

dump this:
/home/user42/data/gcc-csmith-1201/gcc-install/bin/gcc -O2 fuzzer-file-37731.c
======================
during RTL pass: expand
fuzzer-file-37731.c: In function ‘c’:
fuzzer-file-37731.c:5:6: internal compiler error: in do_jump_1, at dojump.c:207
    5 | void c() {
      |      ^
0x6e6d97 do_jump_1
        .././../gcc-source/gcc/dojump.c:207
0xb49847 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        .././../gcc-source/gcc/expr.c:10242
0xb4f24f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        .././../gcc-source/gcc/expr.c:10502
0xa9b916 expand_normal
        .././../gcc-source/gcc/expr.h:307
0xa9b916 do_compare_and_jump
        .././../gcc-source/gcc/dojump.c:1257
0xa9d929 do_jump_1
        .././../gcc-source/gcc/dojump.c:219
0xa238e0 expand_gimple_cond
        .././../gcc-source/gcc/cfgexpand.c:2645
0xa240fc expand_gimple_basic_block
        .././../gcc-source/gcc/cfgexpand.c:5928
0xa25ce7 execute
        .././../gcc-source/gcc/cfgexpand.c:6795
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

It works fine with gcc-8 and below.

[Bug middle-end/104402] [9/10/11/12 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |8.1.0
   Last reconfirmed|                            |2022-02-05
   Target Milestone|---                         |9.5
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
      Known to fail|                            |9.1.0
            Summary|ICE on valid code: in       |[9/10/11/12 Regression] ICE
                   |do_jump_1, at dojump.c      |on valid code caused by not
                   |                            |lowering complex int
                   |                            |compare inside a COND_EXPR

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

The problem is obvious complex lowering does not handle COND_EXPR.
In GCC 8.x we had:

  _4 = a.1_3 != __complex__ (0, 0);
  _6 = _4 ? 3 : 2;

While in GCC 9+ we have:
  _5 = a.1_3 != __complex__ (0, 0) ? 3 : 2;

Complex lowering didn't lower the 9+ IR.

Also here is a better testcase:
_Complex int a;
char b;
int main() {}
void c() {
  if (b != 2 + (long)(a != 0 ^ 0))
    __builtin_abort();
}

[Bug middle-end/104402] [9/10/11/12 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 52358
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52358&action=edit
Patch which I am going to test

Not the best patch but solves the issue. I will clean it up later tonight.

[Bug middle-end/104402] [9/10/11/12 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So thinking about this, my patch does not work for the case where we have:
complex = complex == complex ? complex : complex;

I don't know if that will show up or not but it is still an issue.
I will leave this for someone else to fix.

[Bug middle-end/104402] [9/10/11/12 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think the best would be to to keep the condition split out since that's
desirable anyway from an IL perspective (we've only covered VEC_COND_EXPR
there).

> grep '\?' t.c.*
t.c.039t.evrp:  _7 = _4 ? 3 : 2;

so EVRP introduces this.

t.c.108t.forwprop2:  _5 = a.1_3 != __complex__ (0, 0) ? 3 : 2;

and forwprop moves the condition in.

A quick workaround would thus be to disable propagating complex compares
into COND_EXPRs from forwprop but then treating _Complex like vector and
forcing is_gimple_condexpr to return false for composite types would be
a good step with likely not much fallout.

Btw, since vector type equality compares can return a bool as well we can
in theory see

  vec1 != vec2 ? scalar1 : scalar2;

which we might not handle in vector lowering either.  is_gimple_condexpr
is the predicate to adjust here.  For example like the following (but
the factoring with is_gimple_condexpr_for_cond makes it a bit awkwardly
inefficient):

diff --git a/gcc/gimple-expr.cc b/gcc/gimple-expr.cc
index 05b12747499..b71f7afb686 100644
--- a/gcc/gimple-expr.cc
+++ b/gcc/gimple-expr.cc
@@ -615,6 +615,9 @@ is_gimple_condexpr_1 (tree t, bool allow_traps)
 bool
 is_gimple_condexpr (tree t)
 {
+  if (COMPARISON_CLASS_P (t)
+      && TREE_CODE (TREE_TYPE (TREE_OPERAND (t, 0))) == COMPLEX_TYPE)
+    return false;
   return is_gimple_condexpr_1 (t, true);
 }

[Bug middle-end/104402] [9/10/11/12 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:70430001b74d0f67386a6b3642c857b3389cd5d0

commit r12-7080-g70430001b74d0f67386a6b3642c857b3389cd5d0
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Feb 7 09:31:07 2022 +0100

    middle-end/104402 - split out _Complex compares from COND_EXPRs

    This makes sure we always have a _Complex compare split to a
    different stmt for the compare operand in a COND_EXPR on GIMPLE.
    Complex lowering doesn't handle this and the change is something
    we want for all kind of compares at some point.

    2022-02-07  Richard Biener  <rguenther@suse.de>

            PR middle-end/104402
            * gimple-expr.cc (is_gimple_condexpr): _Complex typed
            compares are not valid.
            * tree-cfg.cc (verify_gimple_assign_ternary): For COND_EXPR
            check is_gimple_condexpr.

            * gcc.dg/torture/pr104402.c: New testcase.

[Bug middle-end/104402] [9/10/11 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |12.0
            Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE on
                   |on valid code caused by not |valid code caused by not
                   |lowering complex int        |lowering complex int
                   |compare inside a COND_EXPR  |compare inside a COND_EXPR

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug middle-end/104402] [9/10/11 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

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

commit r11-9658-gcfc310faea6c2ff32b451f8b4842783ecece761c
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Feb 7 09:31:07 2022 +0100

    middle-end/104402 - split out _Complex compares from COND_EXPRs

    This makes sure we always have a _Complex compare split to a
    different stmt for the compare operand in a COND_EXPR on GIMPLE.
    Complex lowering doesn't handle this and the change is something
    we want for all kind of compares at some point.

    2022-02-07  Richard Biener  <rguenther@suse.de>

            PR middle-end/104402
            * gimple-expr.c (is_gimple_condexpr): _Complex typed
            compares are not valid.
            * tree-cfg.c (verify_gimple_assign_ternary): For COND_EXPR
            check is_gimple_condexpr.

            * gcc.dg/torture/pr104402.c: New testcase.

    (cherry picked from commit 70430001b74d0f67386a6b3642c857b3389cd5d0)

[Bug middle-end/104402] [9/10 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

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

commit r10-10594-gfa26d65dfb41e527bd0db3af3ec2a6ac052019f4
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Feb 7 09:31:07 2022 +0100

    middle-end/104402 - split out _Complex compares from COND_EXPRs

    This makes sure we always have a _Complex compare split to a
    different stmt for the compare operand in a COND_EXPR on GIMPLE.
    Complex lowering doesn't handle this and the change is something
    we want for all kind of compares at some point.

    2022-02-07  Richard Biener  <rguenther@suse.de>

            PR middle-end/104402
            * gimple-expr.c (is_gimple_condexpr): _Complex typed
            compares are not valid.
            * tree-cfg.c (verify_gimple_assign_ternary): For COND_EXPR
            check is_gimple_condexpr.

            * gcc.dg/torture/pr104402.c: New testcase.

    (cherry picked from commit 70430001b74d0f67386a6b3642c857b3389cd5d0)

[Bug middle-end/104402] [9 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
      Known to fail|                            |9.5.0
   Target Milestone|9.5                         |10.4
             Status|ASSIGNED                    |RESOLVED

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for GCC 10.4.