> >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? 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 >
