[Bug c++/108737] New: Apparent miscompile of infinite loop on gcc trunk in cddce2 pass

[Bug c++/108737] New: Apparent miscompile of infinite loop on gcc trunk in cddce2 pass

[njs at pobox dot com]

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

            Bug ID: 108737
           Summary: Apparent miscompile of infinite loop on gcc trunk in
                    cddce2 pass
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: njs at pobox dot com
  Target Milestone: ---

There's a meme going around about strange compilation outputs caused
infinite-loop-related UB, and while discussing it a friend stumbled on this
weird behavior:

https://godbolt.org/z/qfj1jabMW

C++ code is:

extern int foo();

void blah() {
    int x = foo();
    while (1) {
        if(x) foo();
    }
}


When compiled with whatever "gcc trunk" means on compiler explorer, and with
-O3 (but not -O2), as C++ (but not C), then gcc reduces this to a single call
to `foo()` followed by an empty infinite loop:

blah():
        sub     rsp, 8
        call    foo()
.L2:
        jmp     .L2

As far as I can tell, there's no UB here -- 'foo' being extern means it might
do anything, and infinite loops with side-effects are well-defined in C++. So
this seems like a straight-up optimizer bug?

Poking through the pass analysis in CE, it looks like the output of "unrolljam
(tree)" is still correct, but then the output of the next pass "cddce2 (tree)"
has deleted everything. Somehow it concludes that the hoisted `if` can be
eliminated? idgi.

[Bug tree-optimization/108737] [13 Regression] Apparent miscompile of infinite loop on gcc trunk in cddce2 pass

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Apparent miscompile of      |[13 Regression] Apparent
                   |infinite loop on gcc trunk  |miscompile of infinite loop
                   |in cddce2 pass              |on gcc trunk in cddce2 pass
   Last reconfirmed|                            |2023-02-09
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Target Milestone|---                         |13.0
           Keywords|                            |needs-bisection
          Component|c++                         |tree-optimization
            Version|unknown                     |13.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
C++ has the forward progress guarantee, in case 'x' is false there's an endless
loop which is undefined behavior.

Now, the same happens with C and with -fno-finite-loops, so there's something
amiss here.

-funswitch-loops is necessary, but GCC 12 doesn't seem to be affected ...

[Bug tree-optimization/108737] [13 Regression] Apparent miscompile of infinite loop on gcc trunk in cddce2 pass since r13-3875

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
                 CC|                            |jakub at gcc dot gnu.org
            Summary|[13 Regression] Apparent    |[13 Regression] Apparent
                   |miscompile of infinite loop |miscompile of infinite loop
                   |on gcc trunk in cddce2 pass |on gcc trunk in cddce2 pass
                   |                            |since r13-3875
           Keywords|needs-bisection             |

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The foo definition could be e.g.
extern "C" void exit (int);
int foo() {
  static int cnt;
  if (cnt++ == 0)
    return 1;
  if (cnt > 42)
    exit (0);
  return 0;
}

Yes, if first invocation of foo returns 0, then it would invoke UB in C++, but
if it returns non-zero and isn't const or pure, it can't be optimized this way.

Started with r13-3875-g9e11ceef165bc074c2fc85b8ddece606b24e710b

[Bug tree-optimization/108737] [13 Regression] Apparent miscompile of infinite loop on gcc trunk in cddce2 pass since r13-3875

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will investigate.

[Bug tree-optimization/108737] [13 Regression] Apparent miscompile of infinite loop on gcc trunk in cddce2 pass since r13-3875

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think this is another case where control dependences do not work as intended.

Marking useful stmt: foo ();

and we have

  <bb 2> [local count: 3508266]:
  x_4 = foo ();
  if (x_4 != 0)
    goto <bb 12>; [33.00%]
  else
    goto <bb 7>; [67.00%]

  <bb 12> [local count: 1157728]:

  <bb 3> [local count: 116930483]:

  <bb 5> [local count: 116930483]:
  foo ();
  goto <bb 3>; [100.00%]


and BB5 is control dependent on BB3 (on the edge 3->5), so we mark the
block necessary but since there's nothing in it we do not make its
control dependences necessary.

I think what triggers this latent bug is the "double" forwarder with
the call in the latch block rather than in the header when one tries
this on

extern int foo();

void blah()
{
  int x = foo();
  if (x)
    while (1) foo ();
}

it's probably latent with a GIMPLE testcase.

[Bug tree-optimization/108737] [13 Regression] Apparent miscompile of infinite loop on gcc trunk in cddce2 pass since r13-3875

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
I botched the changelog.  Fixed with the following, but latent everywhere.

commit 338739645b8e5bf34636d8d4829d7650001ad08c (origin/master, origin/HEAD)
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Feb 10 10:28:29 2023 +0100

    tree-optimization/106722 - fix CD-DCE edge marking

    The following fixes a latent issue when we mark control edges but
    end up with marking a block with no stmts necessary.  In this case
    we fail to mark dependent control edges of that block.

            PR tree-optimization/106722
            * tree-ssa-dce.cc (mark_last_stmt_necessary): Return
            whether we marked a stmt.
            (mark_control_dependent_edges_necessary): When
            mark_last_stmt_necessary didn't mark any stmt make sure
            to mark its control dependent edges.
            (propagate_necessity): Likewise.

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