On 01/06/2017 11:07 AM, Richard Biener wrote: > 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. >
Yes, I'm working on a patch for that. M.
