[Bug c/110874] New: ice with -O2 with recent gcc

[Bug c/110874] New: ice with -O2 with recent gcc

[dcb314 at hotmail dot com]

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

            Bug ID: 110874
           Summary: ice with -O2 with recent gcc
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 55675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55675&action=edit
C source code

The attached C code, when compiled by recent gcc trunk and -O2, does this:

foundBugs $ ~/gcc/results/bin/gcc -c -w -O2 bug945.c
buildData/keep/in.18686.c: In function ‘func_56’:
buildData/keep/in.18686.c:1184:17: note: the ABI for passing parameters with
32-byte alignment has changed in GCC 4.6
gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
foundBugs $ 

-O1 is fine:

foundBugs $ ~/gcc/results/bin/gcc -c -w -O1 bug945.c
buildData/keep/in.18686.c: In function ‘func_56’:
buildData/keep/in.18686.c:1184:17: note: the ABI for passing parameters with
32-byte alignment has changed in GCC 4.6
foundBugs $ 

Yesterday's compiler (g:01b0c36ba0c3bbe6) seems fine, but today's
(g:0460c1221627938b),
some 36 commits later, does not.

I have a reduction running.

It seems a side issue that -w was given to the compiler, but it still prints
out notes about things that happened a long time ago (gcc 4.6).

[Bug c/110874] ice with -O2 with recent gcc

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
Stack backtrace seems to be:

#0  0x0000000000a0b511 in operand_compare::verify_hash_value (flags=0, 
    this=<optimized out>, arg0=<optimized out>, arg1=<optimized out>, 
    ret=<optimized out>) at ../../trunk.year/gcc/fold-const.cc:4074
#1  operand_compare::operand_equal_p (
    this=0x2efbbd8 <default_compare_instance>, arg0=0x7fffe9c9fc60, 
    arg1=0x7fffe9cc8e10, flags=0) at ../../trunk.year/gcc/fold-const.cc:3090
#2  0x0000000000a04162 in operand_equal_p (arg0=0x7fffe9c9fc60, 
    arg1=0x7fffe9cc8e10, flags=16) at ../../trunk.year/gcc/fold-const.cc:4105
#3  0x0000000001dde083 in gimple_bitwise_inverted_equal_p (
    expr1=0x7fffe9c9fc60, expr2=expr2@entry=0x7fffe9cc8e10, 
    valueize=valueize@entry=0x106ee10 <rpo_vn_valueize(tree_node*)>)
    at ../../trunk.year/gcc/gimple-match-head.cc:284

Looking for the word "invert" in the range of git hashes gives:

$ grep invert /tmp/0
    Slightly improve bitwise_inverted_equal_p comparisons
    This slighly improves bitwise_inverted_equal_p
            * gimple-match-head.cc (gimple_bitwise_inverted_equal_p): Valueize
    Move `~X & X` and `~X | X` over to use bitwise_inverted_equal_p
    bitwise_inverted_equal_p. It also allows us to remove 2 other patterns
            use bitwise_inverted_equal_p, removing :c as
bitwise_inverted_equal_p
$ 

This is commit:

commit ee20be8325f7f257ba91a0201cfb3bd6bfbceba9
Author: Andrew Pinski <apinski@marvell.com>
Date:   Sat Jul 29 16:29:09 2023 -0700

    Slightly improve bitwise_inverted_equal_p comparisons

I can't be sure yet, but that commit is a likely candidate.
Perhaps Andrew would be willing to offer their opinion ?

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
            Version|unknown                     |14.0
   Target Milestone|---                         |14.0
          Component|c                           |middle-end
           Keywords|                            |ice-on-valid-code
            Summary|ice with -O2 with recent    |[14 Regression] ice with
                   |gcc                         |-O2 with recent gcc
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
   Last reconfirmed|                            |2023-08-02

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Let me look into it ...

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this might be the common attribute on an local variable decl that is
causing the issue ....

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reduced testcase:
```
struct S1 {
  unsigned f0;
};
static int g_161;
void func_109(unsigned g_227, unsigned t) {
  struct S1 l_178;
  int l_160 = 0x1FAE99D5L;
  int *l_230[] = {&l_160};
  if (l_160) {
    for (l_178.f0 = -7; l_178.f0;) {
      ++g_227;
      break;
    }
    (g_161) = g_227;
  }
  (g_161) &= t;
}
```
There is a stack overflow while executing the FRE pass.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 55679
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55679&action=edit
C source code

Another test case.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Andrew Pinski from comment #4)
> There is a stack overflow while executing the FRE pass.

I can confirm over 100,000 stack frames.

Which -f flag causes the FRE pass to be executed ?
I assume it is in -O2, but not in -O1.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to David Binderman from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > There is a stack overflow while executing the FRE pass.
> 
> I can confirm over 100,000 stack frames.
> 
> Which -f flag causes the FRE pass to be executed ?
> I assume it is in -O2, but not in -O1.

Fre is enabled at -O1 but the IR changes before fre. I have not looked into
what changes to the IR on why there is a difference between -O1 and -O2 yet.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Oh the difference between -O1 and -O2 is due to in fre:
  /* At -O[1g] use the cheap non-iterating mode.  */
  bool iterate_p = may_iterate && (optimize > 1);

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(gdb) p debug_tree(expr1)
 <ssa_name 0x7ffff780df78
    type <integer_type 0x7ffff78215e8 int sizes-gimplified public SI
        size <integer_cst 0x7ffff7802fd8 constant 32>
        unit-size <integer_cst 0x7ffff7825000 constant 4>
        align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x7ffff78215e8 precision:32 min <integer_cst 0x7ffff7802f90 -2147483648> max
<integer_cst 0x7ffff7802fa8 2147483647>
        pointer_to_this <pointer_type 0x7ffff7829b28>>
    visited
    def_stmt g_227.1_3 = (int) g_227_8;
    version:3>
$3 = void
(gdb) up -1
#0  gimple_bitwise_inverted_equal_p (expr1=0x7ffff79db048,
expr2=0x7ffff79db3a8, valueize=0x11ba180 <rpo_vn_valueize(tree_node*)>) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-match-head.cc:278
278       if (expr1 == expr2)
(gdb) p debug_tree(expr1)
 <ssa_name 0x7ffff79db048
    type <integer_type 0x7ffff7821690 unsigned int sizes-gimplified public
unsigned SI
        size <integer_cst 0x7ffff7802fd8 constant 32>
        unit-size <integer_cst 0x7ffff7825000 constant 4>
        align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff7821690 precision:32 min <integer_cst 0x7ffff7825018 0> max <integer_cst
0x7ffff7802fc0 4294967295>
        pointer_to_this <pointer_type 0x7ffff7831690>>
    visited
    def_stmt g_161.3_5 = (unsigned int) g_161.2_4;
    version:5>
$4 = void



Value numbering stmt = g_161.2_4 = g_161;
Setting value number of g_161.2_4 to g_227.1_3 (changed)
g_227.1_3 is available for g_227.1_3
Value numbering stmt = g_161.3_5 = (unsigned int) g_161.2_4;
g_227.1_3 is available for g_227.1_3
Applying pattern match.pd:4207, gimple-match-4.cc:4064
Applying pattern match.pd:4299, gimple-match-4.cc:4122
Match-and-simplified (unsigned int) g_161.2_4 to g_227_8
RHS (unsigned int) g_161.2_4 simplified to g_227_8
Setting value number of g_161.3_5 to g_227_15 (changed)
Making available beyond BB6 g_161.3_5 for value g_227_15
Value numbering stmt = _6 = g_161.3_5 & t_17(D);



So when we go and handle gimple_nop_convert here and we loop between the two.
So we just need to limit gimple_bitwise_inverted_equal_p to only one look
through I think ...

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am not happy with the patch I came up with but it does reduce the amount of
iterating and 100% makes sure it is bound so it will work.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2023-August/
                   |                            |626131.html
           Keywords|                            |patch

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626131.html

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 110886 has been marked as a duplicate of this bug. ***

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |shaohua.li at inf dot ethz.ch

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 110887 has been marked as a duplicate of this bug. ***

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 110895 has been marked as a duplicate of this bug. ***

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:91c963ea6f845a0c59b7523a5330b8d3ed1beb6a

commit r14-2978-g91c963ea6f845a0c59b7523a5330b8d3ed1beb6a
Author: Andrew Pinski <apinski@marvell.com>
Date:   Wed Aug 2 14:49:00 2023 -0700

    Fix PR 110874: infinite loop in gimple_bitwise_inverted_equal_p with fre

    This changes gimple_bitwise_inverted_equal_p to use a 2 different match
patterns
    to try to match bit_not wrapped with a possible nop_convert and a
comparison
    also wrapped with a possible nop_convert. This is to avoid being recursive.

    OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

    gcc/ChangeLog:

            PR tree-optimization/110874
            * gimple-match-head.cc (gimple_bit_not_with_nop): New declaration.
            (gimple_maybe_cmp): Likewise.
            (gimple_bitwise_inverted_equal_p): Rewrite to use
gimple_bit_not_with_nop
            and gimple_maybe_cmp instead of being recursive.
            * match.pd (bit_not_with_nop): New match pattern.
            (maybe_cmp): Likewise.

    gcc/testsuite/ChangeLog:

            PR tree-optimization/110874
            * gcc.c-torture/compile/pr110874-a.c: New test.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.