From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67547 invoked by alias); 27 Jun 2017 19:53:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 67406 invoked by uid 89); 27 Jun 2017 19:53:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Jun 2017 19:53:15 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8A43AB598E; Tue, 27 Jun 2017 19:53:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8A43AB598E Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=aoliva@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8A43AB598E Received: from freie.home (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 144C117C65; Tue, 27 Jun 2017 19:53:12 +0000 (UTC) Received: from livre (livre.home [172.31.160.2]) by freie.home (8.15.2/8.15.2) with ESMTP id v5RJot2l024712; Tue, 27 Jun 2017 16:50:55 -0300 From: Alexandre Oliva To: Olivier Hainque Cc: GCC Patches , Nicolas Roche Subject: Re: fix libcc1 dependencies in toplevel Makefile References: Date: Tue, 27 Jun 2017 19:53:00 -0000 In-Reply-To: (Olivier Hainque's message of "Mon, 26 Jun 2017 09:16:44 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-06/txt/msg02093.txt.bz2 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 ensures libcc1 will be >> built after GCC in bootstrap scenarios; it might do so under 'make >> bootstrap', but probably not under 'make all-libcc1'. I think we may >> need some additional bootstrap-only explicit dependency for that to work >> properly. > 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. target-libgcc, look below the following comments in Makefile.in: # Dependencies for target modules on other target modules are # described by lang_env_dependencies; the defaults apply to anything # not mentioned there. plus, maybe-configure*-target-libgcc depend on maybe-all*-gcc (see above those comments). The precise deps vary per bootstrap level, or non-bootstrap. But after the proposed patch there are no such deps for libcc1 in the bootstrap case, so we might very well attempt to build libcc1 in parallel with gcc. We shouldn't do that. But then, it all works out because we only build all-host after bootstrap is complete; all-stage* doesn't depend on libcc1 at all. > and I don't see other deps for these either. > I don't see why the sequencing constraints for libcc1 should be tighter > than those for the target libraries. It was not about making them tighter, just about making them present. Right now, in the bootstrap case, they're entirely implicit, by the fact that we complete bootstrap first, then proceed to build all-host all-target. This deserves at least a comment somewhere, perhaps next to libcc1 in Makefile.def, or next to depgcc. Something to the effect that depgcc brings in a necessary dependency that is implicit in the bootstrap case by the fact that we firt bootstrap, then proceed to build all-host all-target. Perhaps instead of depgcc=true, we should have a new flag in dependencies that indicates the dep should be non-bootstrap only. Or maybe the code that implements dependencies could figure it out on its own, when it sees a dep between a non-bootstrap module and a bootstrap one, and generate the deps within @if gcc-no-bootstrap/@endif. I think this would get us the behavior we want in both bootstrap and non-bootstrap cases, including the libcc1 configure dep that, as it is, might cause GCC to be configured in parallel given the right (or rather wrong) conditions. On Jun 27, 2017, Olivier Hainque wrote: >> On Jun 26, 2017, at 09:16 , Olivier Hainque wrote: > make -j 32 BOOT_LDFLAGS=-Wl,--stack=0x2000000 CC=gcc 'ADAFLAGS=-W > -Wall -gnatpg -gnata -gnatws -gnatU -gnatyN' CXXFLAGS=-O2 > BOOT_CFLAGS=-O2 CFLAGS=-O2 'LN_S=cp -p' 'BOOT_ADAFLAGS=-gnatpgn > -gnatU' 'STAGE1_CFLAGS=-O2 -O0 -g' bootstrap Thanks. Given that 'bootstrap' is the only requested make target, we can be assured that something iffy took place. What I can't figure out is how we even tried to build libcc1 during bootstrap, under that configuration, because the current Makefile would only do that with all-host, after bootstrap is complete. > From the logs of discussions we tracked, the understanding > of the dependency issue was that we *had* (before the patch), > possibilities to have stage_current and maybe-all-gcc targets > built concurrently, via >> configure-target-libquadmath: stage_current >> all-target-libquadmath: configure-target-libquadmath >> maybe-all-target-libquadmath: all-target-libquadmath >> all-target: maybe-all-target-libquadmath > on the one hand, >> all-libcc1: maybe-all-gcc >> maybe-all-libcc1: all-libcc1 >> all-host: maybe-all-libcc1 > on the other hand. > Does that make sense ? Yeah. Running all-gcc While unstage does its directory-moving dance can't be good. We can't have them both. So, would you like to give the automatic figuring out of non-bootstrap-on-bootstrap deps in dependencies, and guard them between @if gcc-no-bootstrap and @endif (then both configure- and all- libcc1 deps would be adjusted this way)? (I'm not saying it should be trivial to do or anything like that; I'm not all that familiar with it and I'd have to figure it out myself if I were to do it, but I think that would be better than adding yet another means of introducing dependencies, while leaving another risky dep in place) Thanks, -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer