[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO
hubicka at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Thu Nov 20 22:43:00 GMT 2014
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63968
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
/* If we wanted to, we could actually do a real increase by redeleting and
inserting. However, this would require O (log n) time. So just bail out
for now. */
if (fibheap_comp_data (heap, key, data, node) > 0)
return NULL;
It is clearly bug in the old implementation. Increase is quite easy to handle:
you just remember the increased value and if your find_min returns one where
value has increased, just re-insert it and get another minimum.
This requires to store two keys, that is probably not good for generic
template. Perhaps bb-reorder can just see if it is increasing and perform
delete+insert. Its loop is not perofrmance critical (inliner did so and it was
too slow in that case)
More information about the Gcc-bugs
mailing list