[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>]

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)