Re: [-fcompare-debug] var tracking options are not optimization options

[Alexandre Oliva <aoliva at redhat dot com>]

On Jan  5, 2017, Jakub Jelinek <jakub@redhat.com> wrote:

> You've just changed the hash function and my mail was about the fact that
> it is not enough.

Sorry, it wasn't clear 'enough for what'.  It's enough to fix the
bug/symptom I had observed and intended to fix, but yes, there is
another latent -fcompare-debug bug with a very different symptom that
the patch did not even attempt to address (because I had not even
realized we had that bug ;-)

> With your patch, both functions
> will hash the same (that is ok), but as ICF for functions that hash the same
> also performs memcmp on the OPTIMIZATION_NODE content, they will compare
> the same in one case (-g0) and not in the other one (-g) and so ICF will
> merge them in one case and not in the other one.

Whereas without the proposed patch, ICF will also merge them in one case
and not in the other.  The patch does not change that, it just
introduces a situation in which hashes that used to be different become
the same, but still without a match for merging.

> BTW, seems the above exact case ICEs actually.

Both with and without the proposed patch, I suppose.

Anyway, would you please file a bug report about this, and copy me?  I
might be able to have a look into this one when I get a chance.

> We need to deal not just with the iteration order, but also with equality
> of functions, otherwise ICF will do something depending on -g vs. -g0.

Agreed.  But IMHO that's two different, unrelated bugs.  Maybe more ;-)

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer