The difference is that the relative order of DECL_UIDs do not change
whether debug info is on or not, but there is no such guarantee when
hashing is involved.
David
On Thu, Jul 18, 2013 at 9:45 AM, Jeff Law <l...@redhat.com> wrote:
> On 07/12/2013 04:13 PM, Cong Hou wrote:
>>
>> GCC bootstrap failed with loop vectorizer turned on by default at O2.
>> The symptom is that the comparison between stage2&3 compilers fails.
>> The root cause is a bug in the file "tree-vect-data-refs.c", where a
>> qsort() function call is used to sort a group of data references using
>> a comparison function called "dr_group_sort_cmp()". In this function,
>> the iterative hash values of tree nodes are used for comparisons. For
>> a declaration tree node, its UID participates in the calculation of
>> the hash value. However, a specific declaration may have different
>> UIDs whether the debug information is switched on/off (-gtoggle). In
>> consequence, the results of comparisons may vary in stage 2&3 during
>> bootstrapping.
>>
>> The following patch fixed the bug. Compiler bootstraps and there is no
>> regressions in regression test. Compiler also bootstraps fine when
>> turning on vectorizer by default. Since this patch may produce
>> difference result (but still correct) than before due to the
>> modification to the comparison function, four test cases are adjusted
>> accordingly. OK for trunk?
>
> If I understand you correctly, you're claiming that the DECL_UID can vary
> based on whether or not we're emitting debug info. This can be seen in
> iterative_hash_expr:
>
>
> default:
> tclass = TREE_CODE_CLASS (code);
>
> if (tclass == tcc_declaration)
> {
> /* DECL's have a unique ID */
> val = iterative_hash_host_wide_int (DECL_UID (t), val);
> }
>
>
> What doesn't make sense to me is your compare_tree looks at the UIDs just as
> well:
>
>
>
>
>> +
>> + default:
>> + tclass = TREE_CODE_CLASS (code);
>> +
>> + /* For var-decl, we could compare their UIDs. */
>> + if (tclass == tcc_declaration)
>> + {
>> + if (DECL_UID (t1) != DECL_UID (t2))
>> + return DECL_UID (t1) < DECL_UID (t2) ? -1 : 1;
>> + break;
>> + }
>> +
>>
>
>
> Why does this work while using iterative_hash_expr fail?
>
> Clearly I'm mis-understanding something.
>
> jeff
