[Bug tree-optimization/114787] [13 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

2024-05-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787

Richard Biener  changed:

   What|Removed |Added

  Known to fail||13.2.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to work||13.2.1

--- Comment #20 from Richard Biener  ---
Fixed.

[Bug tree-optimization/114787] [13 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

2024-05-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787

--- Comment #19 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:715a1df9082b40cf810283632218258ac9c86773

commit r13-8697-g715a1df9082b40cf810283632218258ac9c86773
Author: Richard Biener 
Date:   Wed Apr 24 08:42:40 2024 +0200

tree-optimization/114787 - more careful loop update with CFG cleanup

When CFG cleanup removes a backedge we have to be more careful with
loop update.  In particular we need to clear niter info and estimates
and if we remove the last backedge of a loop we have to also mark
it for removal to prevent a following basic block merging to associate
loop info with an unrelated header.

PR tree-optimization/114787
* tree-cfg.cc (remove_edge_and_dominated_blocks): When
removing a loop backedge clear niter info and when removing
the last backedge of a loop mark that loop for removal.

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

(cherry picked from commit cc48418cfc2e555d837ae9138cbfac23acb3cdf9)

[Bug tree-optimization/114787] [13 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

2024-04-24 Thread hubicka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787

--- Comment #18 from Jan Hubicka  ---
predict.cc queries number of iterations using number_of_iterations_exit and
loop_niter_by_eval and finally using estimated_stmt_executions.

The first two queries are not updating the upper bounds datastructure so that
is why we get around without computing them in some cases.

I guess we can just drop dumping here. We now dump the recorded estimates
elsehwere, so this is somewhat redundant.

[Bug tree-optimization/114787] [13 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

2024-04-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787

Richard Biener  changed:

   What|Removed |Added

  Known to work||14.0
Summary|[13/14 Regression] wrong|[13 Regression] wrong code
   |code at -O1 on  |at -O1 on x86_64-linux-gnu
   |x86_64-linux-gnu (the   |(the generated code hangs)
   |generated code hangs)   |
   Priority|P1  |P2

--- Comment #17 from Richard Biener  ---
Fixed on trunk (but not the -fdump-* side-effect - leaving that to Honza).  The
issue is latent on the branches.