On 01/06/2017 10:46 AM, Jakub Jelinek wrote:
> On Fri, Jan 06, 2017 at 12:49:54AM -0200, Alexandre Oliva wrote:
>> On Jan 5, 2017, Jakub Jelinek <[email protected]> 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 ;-)
>
> Ok, let's do it incrementally then. Your patch is ok for trunk, and we'll
> work on the extra stuff later.
>
> BTW, the ICF hash traversal is what I've been trying to partly solve in
> PR78211, but already in the patch submission mentioned there is at least
> another hash table traversal that still would need adjustments.
>
> Jakub
>
Hi.
Sorry for bigger latency. I'm going to fix the traversal and I was also
thinking about
PerFunction and Target optimization flags. Currently, one can have a pair of
functions
(one having for instance -fvar-tracking, second w/o) and use -fcompare-debug.
This is covered by ICF as it compares function attributes and one function will
have
__attribute__ ((optimize(("-fno-var-tracking")))). Second issue can happen with
LTO,
where one compilation unit can have -fvar-tracking and another not. To be
honest, I'm
unable to trigger divergence in ICF by adding GCC_COMPARE_DEBUG=1 to env
variables.
Ideal solution (next stage1) would be to not compare any 'target' and
'optimization'
attributes of a function. But rather compare just cl_optimization_node and
cl_target_node
with special argument (as suggested by Jakub), that some PerFunction flags
would be ignored
for comparison (all var_tracking_* can be put to this category). Which would
work with -fcompare-debug.
Martin
