From patchwork Wed Oct 26 09:01:22 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rainer Orth X-Patchwork-Id: 79368 Delivered-To: patch@linaro.org Received: by 10.140.97.247 with SMTP id m110csp298028qge; Wed, 26 Oct 2016 02:02:07 -0700 (PDT) X-Received: by 10.99.99.195 with SMTP id x186mr1884671pgb.100.1477472526855; Wed, 26 Oct 2016 02:02:06 -0700 (PDT) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id k4si1265141paz.154.2016.10.26.02.02.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Oct 2016 02:02:06 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-return-439565-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org; spf=pass (google.com: domain of gcc-patches-return-439565-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-439565-patch=linaro.org@gcc.gnu.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:mime-version:content-type; q=dns; s=default; b=mO0eX5Vl5hTg+fZelRQBs5F5jcawuVxRmxi6oH1cULB5MP4vuf VtapQfk6Nr9GNNyNPyqfRfzsmf0KujRbgWzA14idlA2+pS42GFoC3Fhotabln29N NusiMV0Db6kUo4Sw6mX1Go27cchMsmXKLk47CSxD2b9ONXhiC/oECBxlA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:mime-version:content-type; s= default; bh=x7AzyaSyULWkowH5O3Ii6AFsr1k=; b=DdDpGAZ6Y+gz0AEnfW2D DDtuZ5RjOxAXjqjH3CCmiEJo0Dv8tZisXQRk7KWqj5K5yEYr7GWSjEDfEXJvtV1Y 6yeDSEeSPj3wSiMKIvXQ+vnCHXaGxlcwg8ovZ0KGGPzEmCdwX5zv4O5ZR+LptAly T3yCjh2wOxPXBlJNEiukzaY= Received: (qmail 57294 invoked by alias); 26 Oct 2016 09:01:39 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 57209 invoked by uid 89); 26 Oct 2016 09:01:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL, BAYES_00, KAM_ASCII_DIVIDERS, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=collect2, exclude, rth, 2004 X-HELO: smtp.CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE (HELO smtp.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 26 Oct 2016 09:01:28 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 31CA4C2D; Wed, 26 Oct 2016 11:01:26 +0200 (CEST) Received: from smtp.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 2wvYFtDHB6G2; Wed, 26 Oct 2016 11:01:23 +0200 (CEST) Received: from lokon.CeBiTec.Uni-Bielefeld.DE (lokon.CeBiTec.Uni-Bielefeld.DE [129.70.161.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 46098C2C; Wed, 26 Oct 2016 11:01:23 +0200 (CEST) Received: (from ro@localhost) by lokon.CeBiTec.Uni-Bielefeld.DE (8.15.2+Sun/8.15.2/Submit) id u9Q91MXa016326; Wed, 26 Oct 2016 11:01:22 +0200 (MEST) From: Rainer Orth To: gcc-patches@gcc.gnu.org Cc: Mike Stump Subject: [testsuite] Fix linker detection in check_gc_sections_available Date: Wed, 26 Oct 2016 11:01:22 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (usg-unix-v) MIME-Version: 1.0 X-IsSubscribed: yes When testing gcc on Solaris, configured to use /usr/ccs/bin/ld, but with /usr/gnu/bin/ld in PATH, the gcsec* tests are FAILing: FAIL: g++.dg/eh/gcsec1.C -std=gnu++11 (test for excess errors) WARNING: g++.dg/eh/gcsec1.C -std=gnu++11 compilation failed to produce executable FAIL: g++.dg/eh/gcsec1.C -std=gnu++14 (test for excess errors) WARNING: g++.dg/eh/gcsec1.C -std=gnu++14 compilation failed to produce executable FAIL: g++.dg/eh/gcsec1.C -std=gnu++98 (test for excess errors) WARNING: g++.dg/eh/gcsec1.C -std=gnu++98 compilation failed to produce executable Excess errors: ld: fatal: unrecognized option '--' ld: fatal: use the '-z help' option for usage information It turned out that gcc/testsuite/lib/target-supports.exp (check_gc_sections_available) has a strange way of finding the configured linker: # Check if the ld used by gcc supports --gc-sections. set gcc_spec [${tool}_target_compile "-dumpspecs" "" "none" ""] regsub ".*\n\\*linker:\[ \t\]*\n(\[^ \t\n\]*).*" "$gcc_spec" {\1} linker On Solaris, collect2 is used here: *linker: collect2 thus set gcc_ld [lindex [${tool}_target_compile "-print-prog-name=$linker" "" "none" ""] 0] gcc -print-prog-name=collect2 collect2 set ld_output [remote_exec host "$gcc_ld" "--help"] Here, collect2 uses PATH to find ld, despite the compiler default. It turns out that either COMPILER_PATH is used to locate the program, which is set by gcc to include /usr/ccs/bin early, but not when collect2 is invoked directly, in which case it falls back to searching PATH. With GNU ld, --gc-sections support is found if { [ string first "--gc-sections" $ld_output ] >= 0 } { set gc_sections_available_saved 1 but the compiler proper invokes /usr/ccs/bin/ld instead, leading to the observed failures. Some digging discovered that this strange way was introduced in r87040 for NetWare support, but not mentioned in ChangeLog: ------------------------------------------------------------------------ r87040 | rth | 2004-09-03 20:10:08 +0200 (Fri, 03 Sep 2004) | 55 lines [...] gcc/testsuite/ [...] * lib/target-supports.exp (check_visibility_available): Exclude NetWare. Since NetWare support is long gone and many other places in the compiler (like configure scripts) use the expected (and working) -print-prog-name=ld instead, this seems to be the way to go. This is what the following patch does, which fixes the spurious failures on i386-pc-solaris2.12 and sparc-sun-solaris2.12. I plan to apply it to all active branches after more widespread testing, unless Mike (or someone else) finds fault with my argument. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University 2016-10-25 Rainer Orth * lib/target-supports.exp (check_gc_sections_available): Use -print-prog-name=ld to determine linker used. # HG changeset patch # Parent fc195b51be36e044b45302ca1e60063a57ad6060 Fix linker detection in check_gc_sections_available diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -462,9 +462,7 @@ proc check_gc_sections_available { } { } # Check if the ld used by gcc supports --gc-sections. - set gcc_spec [${tool}_target_compile "-dumpspecs" "" "none" ""] - regsub ".*\n\\*linker:\[ \t\]*\n(\[^ \t\n\]*).*" "$gcc_spec" {\1} linker - set gcc_ld [lindex [${tool}_target_compile "-print-prog-name=$linker" "" "none" ""] 0] + set gcc_ld [lindex [${tool}_target_compile "-print-prog-name=ld" "" "none" ""] 0] set ld_output [remote_exec host "$gcc_ld" "--help"] if { [ string first "--gc-sections" $ld_output ] >= 0 } { set gc_sections_available_saved 1