https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Lets reopen this. I agree with other type flags - they seem safe except for
TYPE_ATTRIBUTES of functions I will add compare of today.
> No. But you can't compare restrict qualification by looking at a memory
> reference pair from function A and function B. You'd have to compare
> all data dependences somehow.
>
> You could get some cases by comparing function parameter types specially
> (but global vars also have an issue, as well as decl-by-reference
> aggregate parameters).
Would it be enough to
- require match on arguments/return value types (that should handle function
parameters as well as
- require match on all global variable types
> It seems to me that ICF isn't quite ready for prime time. Let's disable
> it by default for now, ok?
I also read the discussion on IRC and discussed with Jeff.
ICF has triggered interesting issues in alias/thunks areas. For a first time we
output a lot of non-MI thunks on main targets and expand_thunk was getting
things wrong in a nasty ways. ICF also produce a lot of aliases and excercise
symbol table code otherwise rarely used. Here I think it is valuable we fixed
those bugs that were semi-latent for years. I believe we are approaching
steady state - at the moment we do not have any other ICF related PR open. Jeff
suggested to wait 48 hours.
This PR is a result of my code audit I did over weekend. I fully leave the
decision with you. I agree ICF is causing a lot of issues late in release and
disabling it is a safe option. On the other hand I would be happy to work to
get it fixed and working - it is quite useful optimization.
