This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Bug in edge redirection code
- To: Daniel Berlin <dan at cgsoftware dot com>
- Subject: Re: Bug in edge redirection code
- From: Jan Hubicka <jh at suse dot cz>
- Date: Thu, 26 Jul 2001 18:50:43 +0200
- Cc: Jan Hubicka <jh at suse dot cz>, gcc-bugs at gcc dot gnu dot org
- References: <87y9pbps2k.fsf@cgsoftware.com>
>
> Okay, i found why my malloc debugger hates the following code
> (crashing on first->count -= e->count)
>
> 3136 else if (redirect_edge_and_branch (e, target))
> 3137 {
> 3138 /* We successfully forwarded the edge. Now update profile
> 3139 data: for each edge we traversed in the chain, remove
> 3140 the original edge's execution count. */
> 3141 do
> 3142 {
> 3143 first->count -= e->count;
> 3144 first->succ->count -= e->count;
> 3145 first->frequency -= ((e->probability * b->frequency
>
> What happens is that redirect_edge_and_branch calls
> redirect_edge_succ_nodup which sees the edge is already
> present, so it remove_edge's it.
> However, what it just remove_edge'd was "e", so when we get back to
> the above code, having succeeded in forwarding, and try to access e->count,
> we're screwed.
Uhm, I remember myself getting around that by saving the frequencies
and counts in local variables before redirecting.
I am going to send the patch. Thanks!
Honza
> Once you'd redirected e to target, you can't count on e still being
> the edge you redirected, or even valid, because we'll remove it if it was a
> duplicate.
>
> This bug also exists in the slightly older version of
> try_forward_edges on the new-regalloc-branch.
>
> I'm not quite sure how you want to fix this.
>
>
> --Dan
>
> --
> "They say we're 98% water. We're that close to drowning...
> (Picks up his glass of water from the stool...) I like to live
> on the edge...
> "-Steven Wright