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: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 31 Dec 2013 10:32:09 +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>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Dec 31, 2013 at 08:39:02AM +0100, Richard Biener wrote:
> >That said, fold_stmt callers have to be prepared to handle say a normal
> >call becoming noreturn call, consider say:
> >
> >struct A { virtual int foo (); };
> >struct B : public A { int foo () __attribute__((noreturn)); };
> >int B::foo () { __builtin_exit (0); }
> >int bar ()
> >{
> > B b;
> > B *p = &b;
> > return p->foo ();
> >}
>
> Is that a valid specialization though?
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?
Jakub