Hello, During highly parallel builds on fast hosts, we have experienced sporadic bootstrap failures on libquadmath like
In file included from ../../../src/libquadmath/printf/printf_fp.c:39:0:
../../../src/libquadmath/printf/quadmath-printf.h:24:20: fatal error:
.../build/./gcc/include-fixed/limits.h: No such file or directory
#include <limits.h>
A pretty clear sign of a race condition caused by some inaccuracy in the
dependency statements.
Investigation led us to suspect this piece in the toplevel Makefile.in:
all-libcc1: maybe-all-gcc
which differs from all the other dependencies on maybe-all-gcc in that it's
unconditional whereas the other ones are conditioned on @if gcc-no-bootstrap.
(Thanks to Nico Roche, cc'ed for the worked involved in finding this out)
Our understanding is that it's incorrect to have dependencies on maybe-all-gcc
in the bootstrap case; that this should be a dependency on stage_current
instead.
This patch is a proposal to address this by first removing the following
statement in Makefile.def:
dependencies = { module=all-libcc1; on=all-gcc; };
(which emits the dependency unconditionally), then refining the expansion
of "all" targets in Makefile.tpl so they include a possible dep conditioned by
gcc-no-bootstrap, on demand for "host_module"s that ask for it by way of a new
"depgcc" parameter.
We have been using this in-house for months now. The sporadic failures
have disappeared since then and we haven't observed any related fallout
so far.
Bootstrapped and regression tested on x86_64-linux.
OK to commit ?
Thanks in advance for your feedback,
With Kind Regards,
Olivier
2017-06-13 Olivier Hainque <hain...@adacore.com>
* Makefile.def (host_modules): Set depgcc to true for libcc1,
meaning need of a dep on stage_current if gcc-bootstrap and on
maybe-all-gcc otherwise.
(dependencies) Remove unconditional dependency on all-gcc.
* Makefile.tpl ("all" targets): Handle depgcc.
* Makefile.in: Regenerate
libcc1-deps.diff
Description: Binary data
