https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94166
Bug ID: 94166
Summary: [10 Regression] random -fcompare-debug failures since
r10-1913
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhroma at gcc dot gnu.org
CC: jakub at redhat dot com, linkw at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-*-linux-gnu
I've regtested recent r10-7146 version on powerpc64le with -fcompare-debug.
pr88497-*.c and pr92618.c tests give some kind of random results - they may
fail or pass.
So, after running one compilation manually several times like this:
gcc -O2 -fcompare-debug gcc/testsuite/gcc.c-torture/execute/pr92618.c
--save-temps
I finally managed to see final-dumps with difference like "a=b+c" vs "a=c+b".
Than I've added -fdump-tree-all and than found that the difference starts from
'reassoc1' dump. Investigation shows r10-1913 causes that. I've checked that
reverting r10-1913 and related r10-4930 (but without removing their tests,
which were actually under investigation) solved the problem.
I think the problem is using
for(hash_map<tree, v_info_ptr>::iterator it = v_info_map.begin ....) {
...
valid_vecs.quick_push (cand_vec);
}
That loop gives unpredictable order in hash_map iterator and we got random
order of elements in valid_vecs. Later we sort it, but in pr92618.c example it
seems there are two elements are their comparison result is 'equal'.
PS. Actually, I've checked the difference between usual regtest results and
-fcompare-debug and there are a lot of other "more stable" failures, I'll also
file another PR.
