[Bug target/100563] New: [10/11/12 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[Bug target/100563] New: [10/11/12 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[acoplan at gcc dot gnu.org]

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

            Bug ID: 100563
           Summary: [10/11/12 Regression] arm: ICE in
                    arm_gen_dicompare_reg, at config/arm/arm.c:15976
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: arm-eabi
Configured with: /home/alecop01/toolchain/src/gcc/configure
--prefix=/data_sdb/toolchain/cc1s/arm --enable-languages=c,c++
--disable-bootstrap --target=arm-eabi
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210511 (experimental) (GCC)

$ cat test.c
unsigned long long e(void);
void f(int);
void a() {
  short b = -1, c = (int)&b;
  unsigned long long d = e();
  f(b >= d);
}

$ gcc/xgcc -B gcc -c test.c -Og
during RTL pass: expand
test.c: In function ‘a’:
test.c:6:3: internal compiler error: in arm_gen_dicompare_reg, at
config/arm/arm.c:15976
    6 |   f(b >= d);
      |   ^~~~~~~~~
0x112525f arm_gen_dicompare_reg
        /home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.c:15976
0x112525f arm_gen_compare_reg(rtx_code, rtx_def*, rtx_def*, rtx_def*)
        /home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.c:16189
0x151ab0a gen_cstore_cc(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
        /home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.md:7973
0x151aded gen_cstorehf4(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
        /home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.md:8192
0xbe5b98 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
        /home/alecop01/toolchain/src/gcc/gcc/optabs.c:7813
0x921e51 emit_cstore(rtx_def*, insn_code, rtx_code, machine_mode, machine_mode,
int, rtx_def*, rtx_def*, int, machine_mode)
        /home/alecop01/toolchain/src/gcc/gcc/expmed.c:5506
0x922780 emit_store_flag_1
        /home/alecop01/toolchain/src/gcc/gcc/expmed.c:5755
0x922cf1 emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode,
int, int)
        /home/alecop01/toolchain/src/gcc/gcc/expmed.c:6015
0x9238f8 emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, int, int)
        /home/alecop01/toolchain/src/gcc/gcc/expmed.c:6155
0x932be0 do_store_flag
        /home/alecop01/toolchain/src/gcc/gcc/expr.c:12655
0x9336b8 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        /home/alecop01/toolchain/src/gcc/gcc/expr.c:9838
0x93b59c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        /home/alecop01/toolchain/src/gcc/gcc/expr.c:10386
0x933807 expand_expr
        /home/alecop01/toolchain/src/gcc/gcc/expr.h:301
0x933807 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        /home/alecop01/toolchain/src/gcc/gcc/expr.c:8954
0x93b59c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        /home/alecop01/toolchain/src/gcc/gcc/expr.c:10386
0x7d71a9 expand_normal
        /home/alecop01/toolchain/src/gcc/gcc/expr.h:307
0x7d71a9 precompute_register_parameters
        /home/alecop01/toolchain/src/gcc/gcc/calls.c:988
0x7d71a9 expand_call(tree_node*, rtx_def*, int)
        /home/alecop01/toolchain/src/gcc/gcc/calls.c:4450
0x939c5b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        /home/alecop01/toolchain/src/gcc/gcc/expr.c:11408
0x7f27b3 expand_expr
        /home/alecop01/toolchain/src/gcc/gcc/expr.h:301
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.

The issue occurs for a wide variety of -march options, including -march=armv8-a
and -march=armv8.1-m.main.

[Bug target/100563] [10/11/12 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.4

[Bug target/100563] [10/11/12 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

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

--- Comment #1 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Started with r10-3986-gaf74bfeee1faccef25dc0086d4249eb0f127c820:

commit af74bfeee1faccef25dc0086d4249eb0f127c820
Author: Richard Earnshaw <rearnsha@arm.com>
Date:   Fri Oct 18 20:03:50 2019

    [arm] Handle some constant comparisons using rsbs+rscs

[Bug target/100563] [10/11/12 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Er, wow, I'm surprised this hasn't come up before.

The problem is that the cstore_cc pattern in arm.md has no predicates on the
operands and no constraints on the modes of those operands and yet it then
immediately calls arm_gen_compare_reg and expects it to handle what has been
thrown at it.

I'll have to think about this a bit...

[Bug target/100563] [10/11/12 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |rearnsha at gcc dot gnu.org
   Last reconfirmed|                            |2021-05-12
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #3 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
err, no it's not that.  We start off with LEU(x, -1) but because we can't do
that directly, we swap the operand order to GEU(-1, x).  But
arm_gen_dicompare_reg can't handle that, so arm_validize_comparison needs to
push the constant into a register.

[Bug target/100563] [10/11/12 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r12-770-ga451598b2c02e1ca3c62fea272d73a9f31922252
Author: Richard Earnshaw <rearnsha@arm.com>
Date:   Thu May 13 11:42:58 2021 +0100

    arm: correctly handle inequality comparisons against max constants
[PR100563]

    Normally we expect the gimple optimizers to fold away comparisons that
    are always true, but at some lower optimization levels this is not
    always the case, so the back-end has to be able to generate correct
    code in these cases.

    In this example, we have a comparison of the form

      (unsigned long long) op <= ~0ULL

    which, of course is always true.

    Normally, in the arm back-end we handle these expansions where the
    immediate cannot be handled directly by adding 1 to the constant and
    then adjusting the comparison operator:

      (unsigned long long) op < CONST + 1

    but we cannot do that when the constant is already the largest value.

    Fortunately, we observe that the comparisons we need to handle this
    way are either always true or always false, so instead of forming a
    comparison against the maximum value, we can replace it with a
    comparison against the minimum value (which just happens to also be a
    constant we can handle.  So

      op1 <= ~0ULL -> op1 >= 0U
      op1 > ~0ULL -> op1 < 0U

      op1 <= LONG_LONG_INT_MAX -> op1 >= (-LONG_LONG_INT_MAX - 1)
      op1 > LONG_LONG_INT_MAX -> op1 < (-LONG_LONG_INT_MAX - 1)

    gcc:
            PR target/100563
            * config/arm/arm.c (arm_canonicalize_comparison): Correctly
            canonicalize DImode inequality comparisons against the
            maximum integral value.

    gcc/testsuite:
            * gcc.dg/pr100563.c: New test.

[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11/12 Regression] arm:  |[10/11 Regression] arm: ICE
                   |ICE in                      |in arm_gen_dicompare_reg,
                   |arm_gen_dicompare_reg, at   |at config/arm/arm.c:15976
                   |config/arm/arm.c:15976      |

--- Comment #5 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Fixed on trunk so far.

[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r12-772-gefd471a980662f113dad8de0c0ef8593d0d38419
Author: Richard Earnshaw <rearnsha@arm.com>
Date:   Thu May 13 14:52:05 2021 +0100

    testsuite: suppress cast warnings in pr100563.c [PR100563]

    Fix a warning when building on machines that don't have 32-bit pointers

    gcc/testsuite:

            PR target/100563
            * gcc.dg/pr100563.c (dg-options): Add -wno-pointer-to-int-cast.

[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-8408-gecfb8658c04114d87e1000f9924d6c373df0e7fd
Author: Richard Earnshaw <rearnsha@arm.com>
Date:   Thu May 13 11:42:58 2021 +0100

    arm: correctly handle inequality comparisons against max constants
[PR100563]

    Normally we expect the gimple optimizers to fold away comparisons that
    are always true, but at some lower optimization levels this is not
    always the case, so the back-end has to be able to generate correct
    code in these cases.

    In this example, we have a comparison of the form

      (unsigned long long) op <= ~0ULL

    which, of course is always true.

    Normally, in the arm back-end we handle these expansions where the
    immediate cannot be handled directly by adding 1 to the constant and
    then adjusting the comparison operator:

      (unsigned long long) op < CONST + 1

    but we cannot do that when the constant is already the largest value.

    Fortunately, we observe that the comparisons we need to handle this
    way are either always true or always false, so instead of forming a
    comparison against the maximum value, we can replace it with a
    comparison against the minimum value (which just happens to also be a
    constant we can handle.  So

      op1 <= ~0ULL -> op1 >= 0U
      op1 > ~0ULL -> op1 < 0U

      op1 <= LONG_LONG_INT_MAX -> op1 >= (-LONG_LONG_INT_MAX - 1)
      op1 > LONG_LONG_INT_MAX -> op1 < (-LONG_LONG_INT_MAX - 1)

    gcc:
            PR target/100563
            * config/arm/arm.c (arm_canonicalize_comparison): Correctly
            canonicalize DImode inequality comparisons against the
            maximum integral value.

    gcc/testsuite:
            * gcc.dg/pr100563.c: New test.

[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:1d1a690b4dfa224228151fed4bed47c7fe412e0b

commit r10-9821-g1d1a690b4dfa224228151fed4bed47c7fe412e0b
Author: Richard Earnshaw <rearnsha@arm.com>
Date:   Thu May 13 11:42:58 2021 +0100

    arm: correctly handle inequality comparisons against max constants
[PR100563]

    Normally we expect the gimple optimizers to fold away comparisons that
    are always true, but at some lower optimization levels this is not
    always the case, so the back-end has to be able to generate correct
    code in these cases.

    In this example, we have a comparison of the form

      (unsigned long long) op <= ~0ULL

    which, of course is always true.

    Normally, in the arm back-end we handle these expansions where the
    immediate cannot be handled directly by adding 1 to the constant and
    then adjusting the comparison operator:

      (unsigned long long) op < CONST + 1

    but we cannot do that when the constant is already the largest value.

    Fortunately, we observe that the comparisons we need to handle this
    way are either always true or always false, so instead of forming a
    comparison against the maximum value, we can replace it with a
    comparison against the minimum value (which just happens to also be a
    constant we can handle.  So

      op1 <= ~0ULL -> op1 >= 0U
      op1 > ~0ULL -> op1 < 0U

      op1 <= LONG_LONG_INT_MAX -> op1 >= (-LONG_LONG_INT_MAX - 1)
      op1 > LONG_LONG_INT_MAX -> op1 < (-LONG_LONG_INT_MAX - 1)

    gcc:
            PR target/100563
            * config/arm/arm.c (arm_canonicalize_comparison): Correctly
            canonicalize DImode inequality comparisons against the
            maximum integral value.

    gcc/testsuite:
            * gcc.dg/pr100563.c: New test.

[Bug target/100563] [10/11 Regression] arm: ICE in arm_gen_dicompare_reg, at config/arm/arm.c:15976

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

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

--- Comment #9 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Fixed on all branches