> On 26 Jun 2018, at 07:38, Alexandre Oliva wrote:
>
> Here's the patch I'll install if nobody objects in the next few days.
> Tested on x86_64-linux-gnu with a gcc bootstrap tree, a gcc
> non-bootstrap tree, and a binutils+gdb tree.
Thanks a lot for this Alex!
On Jun 11, 2018, Alexandre Oliva wrote:
> On Jun 3, 2018, Alexandre Oliva wrote:
>> On Jun 27, 2017, Alexandre Oliva wrote:
> 1. address the previously-mentioned fragility in the patch I posted, to
> catch all cases of postbootstrap targets and their deps on
> non-postbootstrap targets.
This
On 06/11/2018 08:50 PM, Alexandre Oliva wrote:
> So I see two possible ways to go from now:
>
> 1. address the previously-mentioned fragility in the patch I posted, to
> catch all cases of postbootstrap targets and their deps on
> non-postbootstrap targets.
>
>
> 2. revamp the bootstrap/non-boot
Hi Alex,
Thanks for your feedback and help looking into this.
> On 12 Jun 2018, at 04:50, Alexandre Oliva wrote:
>
> I was missing one possibility: that the problem occurred during the
> post-bootstrap all-host all-target build. As far as I can tell from
> Nicolas' analysis, this was indeed th
On Jun 3, 2018, Alexandre Oliva wrote:
> On Jun 27, 2017, Alexandre Oliva wrote:
>> configuration, because the current Makefile would only do that with
>> all-host, after bootstrap is complete.
> I have extensively studied the dependencies, and I still don't see how
> all-libcc1, that is only
On Jun 27, 2017, Alexandre Oliva wrote:
> On Jun 26, 2017, Olivier Hainque wrote:
>> On Jun 22, 2017, at 14:12 , Alexandre Oliva wrote:
>>> Your patch takes care of the build dependencies of libcc1, which should
>>> avoid some scenarios that might lead to concurrency between staged and
>>> non-
Hi Alex,
(Back from a few days away)
> On 27 Jun 2017, at 21:50, Alexandre Oliva wrote:
>
>> I don't quite understand this: we're using the same prerequisite as target
>> libraries, e.g. all-target-libstdc++-v3 or all-target-libbacktrace
>
> Not quite. Target libraries have deps on e.g. targe
On Jun 26, 2017, Olivier Hainque wrote:
> On Jun 22, 2017, at 14:12 , Alexandre Oliva wrote:
>> Your patch takes care of the build dependencies of libcc1, which should
>> avoid some scenarios that might lead to concurrency between staged and
>> non-staged builds. However, I don't see that it en
Hi Alex,
> On Jun 26, 2017, at 09:16 , Olivier Hainque wrote:
>
>> I'd like to understand better what the concurrency problem is with the
>> current build machinery, before we proceed with this change. If you
>> manage to trigger the problem again, could you try to further analyze
>> build logs
Hello Alex,
Thanks for the review and for the extensive comments on this,
much appreciated :)
> On Jun 22, 2017, at 14:12 , Alexandre Oliva wrote:
>
> On Jun 13, 2017, Olivier Hainque wrote:
>
>> 2017-06-13 Olivier Hainque
>
>> * Makefile.def (host_modules): Set depgcc to true for li
On Jun 13, 2017, Olivier Hainque wrote:
> 2017-06-13 Olivier Hainque
> * 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 depend
> On 15 Jun 2017, at 14:03, Nathan Sidwell wrote:
>
> On 06/14/2017 01:24 PM, Olivier Hainque wrote:
>
>>> I'm happy to try the patch.
>> That would bring useful extra datapoints, Thanks!
>
> I now seem unable to trigger the race with an unpatched source. Sorry
No pb. Thanks for trying.
We w
On 06/14/2017 01:24 PM, Olivier Hainque wrote:
I'm happy to try the patch.
That would bring useful extra datapoints, Thanks!
I now seem unable to trigger the race with an unpatched source. Sorry
--
Nathan Sidwell
> On Jun 14, 2017, at 13:39 , Nathan Sidwell wrote:
>
> Olivier,
>> During highly parallel builds on fast hosts, we have experienced
>> sporadic bootstrap failures on libquadmath like
>
> I have encountered such a bootstrap problem too. I guessed dependency race
> condition, but -j21 was a si
Olivier,
During highly parallel builds on fast hosts, we have experienced
sporadic bootstrap failures on libquadmath like
I have encountered such a bootstrap problem too. I guessed dependency
race condition, but -j21 was a simpler fix :)
I'm happy to try the patch.
nathan
--
Nathan Sidwel
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/
16 matches
Mail list logo