This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix devirtualization ICE (PR tree-optimization/59622)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 31 Dec 2013 12:09:25 +0100
- Subject: Re: [PATCH] Fix devirtualization ICE (PR tree-optimization/59622)
- Authentication-results: sourceware.org; auth=none
- References: <20131230164723 dot GD892 at tucnak dot redhat dot com> <02e66dc6-bc24-4ffc-ae2f-affd1ec287e5 at email dot android dot com> <20131230211416 dot GA27228 at kam dot mff dot cuni dot cz> <20131230222412 dot GF892 at tucnak dot redhat dot com> <47adfd09-7411-4aa5-9782-e888833c6be9 at email dot android dot com> <20131231093208 dot GG892 at tucnak dot redhat dot com> <3246dbc4-3dfa-47d4-b2ff-d36d2f848c1c at email dot android dot com>
> >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
>