Fix PR41454 (dom miscompiles stuff)

Jeff Law law@redhat.com
Thu Sep 24 15:21:00 GMT 2009


On 09/24/09 07:32, Michael Matz wrote:
> Hi,
>
> the basic issue is that dom doesn't call update_stmt early enough, but
> instead queues this to when leaving the block.  That's not going to work
> as leave_block can thread over backedges.  There are counter-measures to
> not generate endless loops by that but they depends on updated statement
> for the target block (a dom parent in our case, hence not already
> processed by leave_block, hence with modified but not updated statements).
> In particular FOR_EACH_SSA_USE_OPERAND doesn't work with unupdated
> statements.
>
> The fix is obviously to call update_stmt early enough.  With that we can
> also do away with the stmts_to_rescan set, that since some time wasn't
> doing interesting things anymore except defering update_stmt calls.  It
> once was used to defer changing virtual ops that are part of the hash
> code, that has to stay the same until avail expressions are removed.  But
> that can't happen anymore, and even more so even the removal code doesn't
> really seem to rely on this awkward condition.
>
> Fixes the testcase, regstrapping on x86_64-linux in progress (all
> langs+Ada).  Okay if that passes?
>
>    
It's been a horribly long time since I looked at any of this code -- I 
guess my only question is under what conditions could we previously 
expose new variables?  Did it only occur for virtuals?  Note, I'm not 
objecting to the patch, just trying to remember why the code was written 
in that way.

As for Richard's comments re: may_have_exposed_new_symbols, I agree, if 
we stop queueing statements for rescanning, all the 
may_have_exposed_new_symbols goo can go away.

jeff





More information about the Gcc-patches mailing list