From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53866 invoked by alias); 31 Jul 2019 09:12:19 -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 53858 invoked by uid 89); 31 Jul 2019 09:12:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy= X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 31 Jul 2019 09:12:18 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id E2B422825B7; Wed, 31 Jul 2019 11:12:15 +0200 (CEST) Date: Wed, 31 Jul 2019 09:15:00 -0000 From: Jan Hubicka To: Jakub Jelinek Cc: Martin =?iso-8859-2?Q?Li=B9ka?= , Jeff Law , gcc-patches@gcc.gnu.org, Michael Matz , Richard Biener Subject: Re: [PATCH] Deduce automatically number of cores for -flto option. Message-ID: <20190731091215.f5yjjaevmvhiyma4@kam.mff.cuni.cz> References: <69d3f527-4086-da6c-e789-469dc389d9eb@redhat.com> <20190730233230.GS15878@tucnak> <87d4b006-bb01-a608-7abe-680dffcc937a@suse.cz> <20190731073407.GU15878@tucnak> <20190731080809.g2uerujjqvsaut74@kam.mff.cuni.cz> <20190731085757.GX15878@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190731085757.GX15878@tucnak> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2019-07/txt/msg01860.txt.bz2 > and see that in some cases jobserver is 0 and in other cases jobserver is 1. > Examples of both: > 0 kw -j2 --jobserver-auth=3,6 -- > total 0 > lrwx------. 1 jakub jakub 64 Jul 31 10:41 0 -> /dev/pts/4 > l-wx------. 1 jakub jakub 64 Jul 31 10:41 1 -> pipe:[75026106] > lr-x------. 1 jakub jakub 64 Jul 31 10:41 10 -> /usr/src/gcc/obj/gcc/libgcc_s.so > lr-x------. 1 jakub jakub 64 Jul 31 10:41 13 -> /usr/lib64/libc.so > lr-x------. 1 jakub jakub 64 Jul 31 10:41 18 -> /usr/src/gcc/obj/gcc/libgcc_s.so > l-wx------. 1 jakub jakub 64 Jul 31 10:41 2 -> /tmp/ccX4y4r3.le > l-wx------. 1 jakub jakub 64 Jul 31 10:41 9 -> pipe:[46167136] > 1 kw -j2 --jobserver-auth=3,6 -- > total 0 > lrwx------. 1 jakub jakub 64 Jul 31 10:41 0 -> /dev/pts/4 > l-wx------. 1 jakub jakub 64 Jul 31 10:41 1 -> /tmp/cchSvmBt > lr-x------. 1 jakub jakub 64 Jul 31 10:41 10 -> /usr/lib64/crtn.o > lrwx------. 1 jakub jakub 64 Jul 31 10:41 2 -> /dev/pts/4 > lr-x------. 1 jakub jakub 64 Jul 31 10:41 3 -> /usr/lib64/crt1.o > lr-x------. 1 jakub jakub 64 Jul 31 10:41 4 -> /usr/lib64/crti.o > lr-x------. 1 jakub jakub 64 Jul 31 10:41 5 -> /usr/src/gcc/obj/gcc/crtbegin.o > lr-x------. 1 jakub jakub 64 Jul 31 10:41 6 -> /usr/src/gcc/obj/gcc/testsuite/gcc/c_lto_20081125_0.o > lr-x------. 1 jakub jakub 64 Jul 31 10:41 7 -> /usr/src/gcc/obj/gcc/testsuite/gcc/c_lto_20081125_1.o > lr-x------. 1 jakub jakub 64 Jul 31 10:41 8 -> /usr/src/gcc/obj/gcc/crtend.o > l-wx------. 1 jakub jakub 64 Jul 31 10:41 9 -> pipe:[46167136] > > so, if one is lucky enough and at least one of the two file descriptors in > MAKEFLAGS --jobserver-auth= is closed, it will work fine, but if they are > open, even when they have nothing to do with make, it will fail miserably. I see, so the problem is that lto-wrapper is executed via plugin from gold which already used the file descriptors for something else? This seems a bit of problem since gold opens it before we get to lto-plugin (most probably) so i do not see how to reliably detect presence of make server. I think the gcc binary can look for jobserv environment, detect jobserv and if it is not available remove jobserver option from it prior going to ld. I think this works since I think link-time gcc can only be executed via gcc/g++/gfortran... wrappers. (unlike lto plugin invoked implicitly for ar/nm etc). Honza > > As a partial workaround, I wonder if jobserver_active_p couldn't check (with > fstat/fstat64) if the file descriptors are pipes. It will still not be 100% > reliable, as when you are unlucky the file descriptor could be some > completely unrelated pipe, but at least better than the current state. > > Jakub