From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13279 invoked by alias); 26 Apr 2011 15:28:39 -0000 Received: (qmail 13263 invoked by uid 22791); 26 Apr 2011 15:28:38 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from snape.CeBiTec.Uni-Bielefeld.DE (HELO smtp-relay.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Apr 2011 15:28:24 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 145EB227; Tue, 26 Apr 2011 17:28:22 +0200 (CEST) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OSNuc0lu4bYw; Tue, 26 Apr 2011 17:28:20 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (manam.CeBiTec.Uni-Bielefeld.DE [129.70.161.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 7EC73225; Tue, 26 Apr 2011 17:28:20 +0200 (CEST) Received: (from ro@localhost) by manam.CeBiTec.Uni-Bielefeld.DE (8.14.4+Sun/8.14.4/Submit) id p3QFSKT8006860; Tue, 26 Apr 2011 17:28:20 +0200 (MEST) From: Rainer Orth To: Ralf Wildenhues Cc: Richard Guenther , Michael Matz , gcc-patches@gcc.gnu.org, Richard Guenther , Paolo Bonzini Subject: Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944) References: <20110418181248.GB26439@gmx.de> Date: Tue, 26 Apr 2011 16:01:00 -0000 In-Reply-To: (Rainer Orth's message of "Tue, 19 Apr 2011 19:37:18 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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 X-SW-Source: 2011-04/txt/msg02049.txt.bz2 Hi Ralf, it's been a week since I answered your questions on this patch. Could you please have a look? Thanks. Rainer >>> I haven't found if there are provisions for in-tree gold, though, and >>> still cannot test that. >> >> I'm not quite sure I understand this statement. I built a combined tree >> with gold enabled a while ago (must've been several months now). >> I might be misunderstanding this. > > I suppose I've been unclear: I'm specificially referring to the current > code for setting gcc_cv_lto_plugin: in the in-tree case, there's nothing > that deals with in-tree gold. > >>> if test $in_tree_ld = yes -a x"$ORIGINAL_PLUGIN_LD_FOR_TARGET" = x"$gcc_cv_ld"; then >>> - if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge 21 -o "$gcc_cv_gld_major_version" -gt 2; then >>> - gcc_cv_lto_plugin=2 >>> - elif test "$ld_is_gold" = yes -a "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -eq 20; then >>> - gcc_cv_lto_plugin=1 >>> - >>> + ld_ver="GNU ld" >>> + # FIXME: ld_is_gold? >> >> What about this FIXME? Did you test gold? Is it not relevant here? >> Can the FIXME go? > > I cannot test gold since it doesn't yet work on Solaris: cf. binutils PR > gold/12525. We made some progress on that front, but the PR is > currently stalled and I had other things on my plate that prevented me > from pushing it. As I said, the current code (before my patch) doesn't > handle in-tree gold, so I don't feel obliged to change that, especially > since I'm in no good position to test. > >>> + ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'` >>> + ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'` >> >> Can you try the expr statements quickly on Tru64? If not, I can do it >> for you ('info Autoconf --index expr' is long and tells of many woes). > > I just tried with /bin/expr and ld_vers set to 2.20.1. OTOH, this isn't > relevant for two reasons: this code is identical to the one determining > ld_vers_major/ld_vers_minor further up in gcc/configure.ac, and GNU ld > (as well as GNU as) aren't currently supported on Tru64 UNIX and I > seriously doubt that will change over the remaining livetime of the > platform. > >> Thanks, and sorry for the delay, > > No worries. I'd just like to get this series of patches out of my queue > (and eventually backported to the 4.6 branch if all issues are sorted > out). Maybe one of the build maintainers finds some time to handle the > current mess that are the linker tests in gcc/configure.ac, compared to > what we do for the assembler. > > Thanks. > Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University