On January 6, 2017 3:49:54 AM GMT+01:00, Alexandre Oliva <aol...@redhat.com> wrote: >On Jan 5, 2017, Jakub Jelinek <ja...@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 ;-)
But can we perhaps solve the iteration order issue by sorting the candidates after sth more stable then, like their DECL_UID? Richard.
