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