Re: [PATCH] PR lto/63968: 175.vpr from cpu2000 fails to build with LTO

2014-11-21 Thread Jan Hubicka
> >Can you verify that the implementation is correct? I tend to remember that I > >introduced the > >lazy incerementation to inliner both for perofrmance and correctness > >reasons. I used to get > >odd orders when keys was increased. > > > >Honza > > Hello. > > What kind of correctness do you

Re: [PATCH] PR lto/63968: 175.vpr from cpu2000 fails to build with LTO

2014-11-21 Thread Martin Liška
On 11/20/2014 10:13 PM, Jan Hubicka wrote: Hello. As I reimplemented fibheap to C++ template, Honza told me that replace_key method actually supports just decrement operation. Old implementation suppress any feedback if we try to increase key: fibheap.c: ... /* If we wanted to, we could ac

Re: [PATCH] PR lto/63968: 175.vpr from cpu2000 fails to build with LTO

2014-11-20 Thread Jan Hubicka
> Hello. > > As I reimplemented fibheap to C++ template, Honza told me that replace_key > method actually > supports just decrement operation. Old implementation suppress any feedback > if we try to increase key: > > fibheap.c: > ... > /* If we wanted to, we could actually do a real increase

[PATCH] PR lto/63968: 175.vpr from cpu2000 fails to build with LTO

2014-11-20 Thread Martin Liška
Hello. As I reimplemented fibheap to C++ template, Honza told me that replace_key method actually supports just decrement operation. Old implementation suppress any feedback if we try to increase key: fibheap.c: ... /* If we wanted to, we could actually do a real increase by redeleting and