This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix CDDCE miscompilation (PR tree-optimization/55018)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>, stevenb dot gcc at gmail dot com, gcc-patches at gcc dot gnu dot org
- Date: Thu, 1 Nov 2012 22:28:02 +0100
- Subject: Re: [PATCH] Fix CDDCE miscompilation (PR tree-optimization/55018)
- References: <CABu31nNbi07+9x4BHpL_6PYN6_rSnEjmG7eA+WBMkmwo0ziwTQ@mail.gmail.com> <201211012026.qA1KQPLF026378@ignucius.se.axis.com> <20121101205853.GO1891@tucnak.redhat.com>
> On Thu, Nov 01, 2012 at 09:26:25PM +0100, Hans-Peter Nilsson wrote:
> > > Attached patch was bootstrapped&tested on
> >
> > gcc/
> > PR tree-optimization/55018
> > * basic-block.h (dfs_find_deadend): New prototype.
> > * cfganal.c (dfs_find_deadend): No longer static. Use bitmap
> > instead of sbitmap for visited.
> > (flow_dfs_compute_reverse_execute): Use dfs_find_deadend here, too.
> > * dominance.c (calc_dfs_tree): If saw_unconnected,
> > traverse from dfs_find_deadend of unconnected b
> > instead of b directly.
> >
> > It seems this caused PR55168, ICE.
>
> As Honza said, it was likely latent, and furthermore seems to be related to
> the flow_dfs_compute_reverse_execute change from Steven (mentioning it
> primarily what should we consider backporting if anything to release
> branches).
Indeed, this patch should not affect loop predictions. Perhaps it prevents
CD-DCE from removing a loop that it previously removed and thus the loop survives
till predict.c and triggers the previously latent bugs?
The patch I attached to the PR is actually incorrect -
estimated_stmt_executions_int already adds the +1 and thus should never return
0. I am looking into proper fix. There is obvious overflow on the other
computation patch, so my best guess is that fixing it will cure the issue.
Honza
>
> Jakub