From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108025 invoked by alias); 22 Jun 2017 12:13:31 -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 108006 invoked by uid 89); 22 Jun 2017 12:13:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=stages, H*Ad:U*roche, olivier, Olivier 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; Thu, 22 Jun 2017 12:13:28 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4073F6573E; Thu, 22 Jun 2017 12:13:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4073F6573E Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=aoliva@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 4073F6573E Received: from freie.home (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 05EA61715F; Thu, 22 Jun 2017 12:13:26 +0000 (UTC) Received: from livre (livre.home [172.31.160.2]) by freie.home (8.15.2/8.15.2) with ESMTP id v5MCCkpx004971; Thu, 22 Jun 2017 09:12:51 -0300 From: Alexandre Oliva To: Olivier Hainque Cc: GCC Patches , Nicolas Roche Subject: Re: fix libcc1 dependencies in toplevel Makefile References: Date: Thu, 22 Jun 2017 12:13:00 -0000 In-Reply-To: (Olivier Hainque's message of "Tue, 13 Jun 2017 14:58:29 +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/msg01654.txt.bz2 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 dependency on all-gcc. > * Makefile.tpl ("all" targets): Handle depgcc. > * Makefile.in: Regenerate This looks reasonable to me. libcc1 is weird. It's not a target library, it doesn't use the current stage tools for building. It might as well not have any deps on the current stage's gcc, if it weren't for the fact that it includes headers from the current stage's gcc and links with current stage's host libraries, and even its configure reads from files created in current stage's gcc configuration. So, it needs to be built after gcc and its host deps are built, and it needs to be configured after gcc is configured. However, it is not part of the bootstrap, and we avoid building it more than once even in a bootstrap build. That's what makes it special and tricky. 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. Furthermore, the patch does not take care of the configure dependencies of libcc1, so I think there might still be room for trouble, depending on what make targets are concurrently requested. I'm not entirely sure this is true, though. 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 to check for e.g. concurrent activation of all-gcc in both the top-level Makefile and the recursed-into-for-stage1 Makefile, or somesuch? Something else worth considering is what the make targets specified in the command line were. All this said, I do agree that explicit deps on maybe-all-gcc are a likely source of trouble; AFAICT all other host modules that are to be built after gcc depend on some target lib too. Perhaps that brings some dep that libcc1 should have too... -- 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