[PATCH] Fix devirtualization ICE (PR tree-optimization/59622)

Richard Biener rguenther@suse.de
Tue Dec 31 11:24:00 GMT 2013


Jan Hubicka <hubicka@ucw.cz> wrote:
>> >I think so, after all don't we set noreturn attribute automatically
>> >even if it is missing when IPA can prove the function never returns?
>> >If we fold_stmt after that, the above testcase even without explicit
>> >noreturn attribute would need cfg cleanup.
>> >
>> >Perhaps gimple_fold_call should punt and not change fndecl if
>!inplace
>> >if some call flags have changed that would require cfg cleanup,
>making
>> >at least fold_stmt_inplace callers not having to deal with it, and
>make
>> >sure fold_stmt callers schedule cleanup_cfg when fold_stmt returns
>> >true?
>> 
>> It would be nice to audit callers and finally document what callers
>are required to do ... I can look at this next week.  I agree that the
>in place variant should avoid these kind of side-effects.
>
>Yep, I think with in-place-fold we really can't do this.
>This make me wonder, how we arrange the statement to be folded later if
>we don't fold
>statements we did not touched by a given pass?

We don't fold all statements, that is a general issue. I have old patches that ensure we at least fold all statements after gimplifying. Propagators should fold what they propagate into. That leaves us with lto which could fold each statement after reading it. I've not done this to avoid differences with regarding to the gimplification issue.

Richard.

>Note that with LTO and invalid C++ program, I think devirtualization
>can return
>a function of a different type just because the slots in virtual tables
>are used
>differently in each unit.  We should not ICE here.
>
>Honza
>> 
>> Meanwhile your patch is ok.
>> 
>> Thanks,
>> Richard.
>> 
>> >	Jakub
>> 




More information about the Gcc-patches mailing list