Re: [PATCH] Fix devirtualization ICE (PR tree-optimization/59622, take 2)

2014-01-03 Thread Jakub Jelinek
On Fri, Jan 03, 2014 at 11:24:53AM +0100, Richard Biener wrote: > works just fine for me but shows > > int (*) () f; > > int _4; > >

Re: [PATCH] Fix devirtualization ICE (PR tree-optimization/59622, take 2)

2014-01-03 Thread Richard Biener
On Fri, 3 Jan 2014, Richard Biener wrote: > On Fri, 3 Jan 2014, Jakub Jelinek wrote: > > > On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote: > > > so if there is a decl then use its type signature, otherwise > > > (indirect calls) use the caller signature (and hope it matches > > >

Re: [PATCH] Fix devirtualization ICE (PR tree-optimization/59622, take 2)

2014-01-03 Thread Richard Biener
On Fri, 3 Jan 2014, Jakub Jelinek wrote: > On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote: > > so if there is a decl then use its type signature, otherwise > > (indirect calls) use the caller signature (and hope it matches > > the callee...). That it later falls back to looking at

Re: [PATCH] Fix devirtualization ICE (PR tree-optimization/59622, take 2)

2014-01-03 Thread Jakub Jelinek
On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote: > so if there is a decl then use its type signature, otherwise > (indirect calls) use the caller signature (and hope it matches > the callee...). That it later falls back to looking at > DECL_ARGUMENTS is odd (probably a FE issue wher

Re: [PATCH] Fix devirtualization ICE (PR tree-optimization/59622, take 2)

2014-01-03 Thread Richard Biener
On Fri, 3 Jan 2014, Jakub Jelinek wrote: > On Fri, Jan 03, 2014 at 11:01:13AM +0100, Richard Biener wrote: > > > Well, see PR59630. The question is if having to handle it everywhere > > > is worth it. > > > > Well, this case happens because we go back to GENERIC which doesn't > > have this featu

Re: [PATCH] Fix devirtualization ICE (PR tree-optimization/59622, take 2)

2014-01-03 Thread Jakub Jelinek
On Fri, Jan 03, 2014 at 11:01:13AM +0100, Richard Biener wrote: > > Well, see PR59630. The question is if having to handle it everywhere > > is worth it. > > Well, this case happens because we go back to GENERIC which doesn't > have this feature. So "everywhere" is somewhat a broad stmt. > It's

Re: [PATCH] Fix devirtualization ICE (PR tree-optimization/59622, take 2)

2014-01-03 Thread Richard Biener
On Fri, 3 Jan 2014, Jakub Jelinek wrote: > On Fri, Jan 03, 2014 at 10:26:44AM +0100, Richard Biener wrote: > > Jakub Jelinek wrote: > > >On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote: > > >> Meanwhile your patch is ok. > > > > > >As discussed in the PR, the patch wasn't sufficien

Re: [PATCH] Fix devirtualization ICE (PR tree-optimization/59622, take 2)

2014-01-03 Thread Jakub Jelinek
On Fri, Jan 03, 2014 at 10:26:44AM +0100, Richard Biener wrote: > Jakub Jelinek wrote: > >On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote: > >> Meanwhile your patch is ok. > > > >As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual > >can appear in the vtable and

Re: [PATCH] Fix devirtualization ICE (PR tree-optimization/59622, take 2)

2014-01-03 Thread Richard Biener
Jakub Jelinek wrote: >On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote: >> Meanwhile your patch is ok. > >As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual >can appear in the vtable and it has pretty much the same properties >as __builtin_unreachable (void retur

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

2014-01-03 Thread Jakub Jelinek
On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote: > Meanwhile your patch is ok. As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual can appear in the vtable and it has pretty much the same properties as __builtin_unreachable (void return value, no arguments, noret