[Bug c/104531] New: ICE in prepare_cmp_insn, at optabs.cc:4547

[Bug c/104531] New: ICE in prepare_cmp_insn, at optabs.cc:4547

[gscfq@t-online.de]

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

            Bug ID: 104531
           Summary: ICE in prepare_cmp_insn, at optabs.cc:4547
           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: ---

Started between 20210905 and 20210919 :


$ cat z1.c
void f (_Complex int y, int x)
{
  #pragma omp atomic compare update seq_cst
  x = x > y ? y : x;
}


$ gcc-12-20220213 -c z1.c -fopenmp
during RTL pass: expand
z1.c: In function 'f':
z1.c:3:11: internal compiler error: in prepare_cmp_insn, at optabs.cc:4547
    3 |   #pragma omp atomic compare update seq_cst
      |           ^~~
0xafd677 prepare_cmp_insn
        ../../gcc/optabs.cc:4547
0xafd711 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, profile_probability)
        ../../gcc/optabs.cc:4692
0x839688 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, profile_probability)
        ../../gcc/dojump.cc:1220
0x8df4a5 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        ../../gcc/expr.cc:9745
0x7c4ea2 expand_gimple_stmt_1
        ../../gcc/cfgexpand.cc:3967
0x7c4ea2 expand_gimple_stmt
        ../../gcc/cfgexpand.cc:4028
0x7c9bd7 expand_gimple_basic_block
        ../../gcc/cfgexpand.cc:6069
0x7cc67e execute
        ../../gcc/cfgexpand.cc:6795

[Bug middle-end/104531] [12 Regression] ICE in prepare_cmp_insn, at optabs.cc:4547

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE in prepare_cmp_insn, at |[12 Regression] ICE in
                   |optabs.cc:4547              |prepare_cmp_insn, at
                   |                            |optabs.cc:4547
           Keywords|                            |ice-on-valid-code
   Target Milestone|---                         |12.0
          Component|c                           |middle-end

[Bug c/104531] [12 Regression] ICE in prepare_cmp_insn, at optabs.cc:4547

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |c
           Keywords|ice-on-valid-code           |ice-on-invalid-code

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this might be invalid code.

The C++ front-end does:
<source>: In function 'void f(__complex__ int, int)':
<source>:3:11: error: invalid operands of types 'int' and '__complex__ int' to
binary '<unknown>'
    3 |   #pragma omp atomic compare update seq_cst
      |           ^~~
<source>:3:11: note:   in evaluation of '<unknown>(int, __complex__ int)'


Without -fopenmp we get:
<source>: In function 'f':
<source>:4:9: error: invalid operands to binary > (have 'int' and 'complex
int')
    4 |   x = x > y ? y : x;
      |         ^

[Bug c/104531] [12 Regression] ICE in prepare_cmp_insn, at optabs.cc:4547

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-02-15
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1

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

Untested fix.

[Bug c/104531] [12 Regression] ICE in prepare_cmp_insn, at optabs.cc:4547

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 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:023327643969d5469902a9ecfa6738a315f9e362

commit r12-7257-g023327643969d5469902a9ecfa6738a315f9e362
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Feb 16 09:27:11 2022 +0100

    openmp: For min/max omp atomic compare forms verify arg types with
build_binary_op [PR104531]

    The MIN_EXPR/MAX_EXPR handling in *build_binary_op is minimal (especially
    for C FE), because min/max aren't expressions the languages contain
directly.
    I'm using those for the
      #pragma omp atomic
      x = x < y ? y : x;
    forms, but e.g. for the attached testcase we normally reject _Complex int
vs. int
    comparisons, in C++ due to MIN/MAX_EXPR we were diagnosing it as invalid
types
    for <unknown> while in C we accept it and ICEd later on.

    The following patch will try build_binary_op with LT_EXPR on the operands
first
    to get needed diagnostics and fail if it returns error_mark_node.

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

            PR c/104531
            * c-omp.cc (c_finish_omp_atomic): For MIN_EXPR/MAX_EXPR, try first
            build_binary_op with LT_EXPR and only if that doesn't return
            error_mark_node call build_modify_expr.

            * c-c++-common/gomp/atomic-31.c: New test.

[Bug c/104531] [12 Regression] ICE in prepare_cmp_insn, at optabs.cc:4547

[jakub at gcc dot gnu.org]

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

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

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

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