------- Comment #12 from rwild at gcc dot gnu dot org 2010-02-28 18:14 -------
Thanks. You are right that the chance for a non-parallelism-related failure
was low, but comparison failures can be due to the phase of the moon literally.
Anyway, here's how I usually debug parallel build failures: rebuild until you
have both a successful and failed build, moving prior build trees away like:
for i in 1 2 3 4; do
mv build build-$i && mkdir build && cd build &&
../gcc/configure ... && make -jN
done
That way one can compare the trees afterward without spurious path name diffs.
Compare the contents of build-$i/stage-{1,2,3}-$host/libgomp with that of a bad
build and in between the three stages. Esp. the libgomp/.deps subdirs and the
config.log and config.status files. Chances are you will find suspect issues
even when looking only at those of the different stages of a single build.
If that all doesn't lead anywhere, then posting the output from a failed build
would be a good idea. Sorry I can't help better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
