This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR68067
- From: Richard Biener <rguenther at suse dot de>
- To: Alan Lawrence <alan dot lawrence at arm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 30 Nov 2015 09:42:41 +0100 (CET)
- Subject: Re: [PATCH] Fix PR68067
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1510271340060 dot 28064 at zhemvz dot fhfr dot qr> <alpine dot LSU dot 2 dot 11 dot 1510271526510 dot 28064 at zhemvz dot fhfr dot qr> <alpine dot LSU dot 2 dot 11 dot 1510281437450 dot 28064 at zhemvz dot fhfr dot qr> <563C817D dot 1060107 at arm dot com> <alpine dot LSU dot 2 dot 11 dot 1511061136580 dot 10078 at zhemvz dot fhfr dot qr> <CAOckXuMnh77Y2unSToB=wiY5vfMBMueaZ4SyG4Yj=RBrfeK0dA at mail dot gmail dot com> <alpine dot LSU dot 2 dot 11 dot 1511231042100 dot 4884 at t29 dot fhfr dot qr> <565871CF dot 6060409 at arm dot com> <56589E4B dot 1080405 at arm dot com>
On Fri, 27 Nov 2015, Alan Lawrence wrote:
> On 27/11/15 15:07, Alan Lawrence wrote:
> > On 23/11/15 09:43, Richard Biener wrote:
> > > On Fri, 20 Nov 2015, Alan Lawrence wrote:
> > >
> > > > ...the asserts
> > > > you suggested in
> > > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D68117#c27)...
> > >>
> > > > So I have to ask, how sure are you that those assertions are(/should
> > > > be!) "correct"? :)
> > >
> > > Ideally they should be correct but they happen to be not (and I think
> > > the intent was that this should be harmless). Basically I tried
> > > to assert that nobody creates stale edge redirect data that is not
> > > later consumed or cleared. Happens to be too optimistic :/
> >
> > Maybe so, but it looks like the edge_var_redirect_map is still suspect here.
> > On
> > the ~~28th call to loop_version, from tree_unswitch_loop, the call to
> > lv_flush_pending_stmts executes (tree-cfg.c flush_pending_stmts):
> >
> > def = redirect_edge_var_map_def (vm);
> > add_phi_arg (phi, def, e, redirect_edge_var_map_location(vm));
> >
> > and BLOCK_LOCATION (redirect_edge_var_map_location(vm)) is
> >
> > <<invalid tree code> 0x7fb7704a80 side-effects addressable asm_written used
> > protected static visited tree_0 tree_2 tree_5>
> >
> > so yeah, next question, how'd that get there...
> >
> > A.
>
> Well, pass_dominator::execute calls redirect_edge_var_map with that edge
> pointer, at which time the edge is from from 32 (0x7fb79cc6e8) to block 20
> (0x7fb7485e38), and locus is 2147483884; and then again, with locus 0.
>
> With no intervening calls to redirect_edge_var_map_clear for that edge,
> loop_version's call to flush_pending_statements then reads
> redirect_edge_var_map_vector for that edge pointer - which is now an edge from
> block 126 (0x7fb7485af8) to 117 (0x7fb74856e8). It sees those locations
> (2147483884 and 0)...
>
> Clearing the edge redirect map at the end of pass_dominator fixes the ICE (as
> would clearing it at the end of each stage, or clearing it at the beginning of
> loop_unswitch, I guess).
>
> I'll post a patch after more testing, but obviously I'm keen to hear if there
> are obvious problems with the approach?
>
> And coming up with a testcase, well, heh - this broke because of identical
> pointers to structures allocated at different times, with intervening
> free...ideas welcome of course!
Yeah. I've pondered with clearing the hashmap after each pass
(and hope no IPA pass would redirect edges). Or even more aggressive,
clear the hashmap as well when we do set_cfun ().
Maybe you can try that?
And no, I don't think any pass expects this stuff to be live across
passes.
Richard.