From patchwork Tue Jun 26 21:04:54 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexandre Oliva X-Patchwork-Id: 167466 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id D8F4CB6F13 for ; Wed, 27 Jun 2012 07:05:26 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1341349527; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Received:From:To:Subject:Date:Message-ID: User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=XxWLp1yNtsfdkXplK8G13A1VGCw=; b=gWhz1OfeR2snT4t wnq7IdtD8rVCtuuCFnBFu2Zy6G5iyjjaNG8SYX1FEOvk5pwhBiyJ4Gu2I2Um11m1 4nSgyWD9b3JUtCSEQcjxf8kBGDYl3kUyxkeVh8XIq3F8pX1fmE8kkKEurgZ4rqwX sK9gPR0b+F1Cvf/1mZ57wOnjegh4= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Received:From:To:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=vrNi8s86Bx1TkTK5oystTu2wVwBLAYeEMC7Iu1LxNF4SEXtSd3Brxyrx2F7vrt np7F/wamCNTXbcegawVWNJEBnT7L15Cmhq1wm9N7xF5Nz/puQkiCoJugFL7rKWMV WIpn8uVuzHO1lUtXWChsIwvqSfuLtOWe8d9ZoJCM011tE=; Received: (qmail 25814 invoked by alias); 26 Jun 2012 21:05:23 -0000 Received: (qmail 25801 invoked by uid 22791); 26 Jun 2012 21:05:22 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, SPF_HELO_PASS, T_RP_MATCHES_RCVD, T_TVD_MIME_NO_HEADERS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Jun 2012 21:05:00 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5QL501b018672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Jun 2012 17:05:00 -0400 Received: from freie (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q5QL4wTr009377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jun 2012 17:05:00 -0400 Received: from livre.localdomain (livre-to-gw.oliva.athome.lsd.ic.unicamp.br [172.31.160.19]) by freie (8.14.5/8.14.5) with ESMTP id q5QL4uk5028364 for ; Tue, 26 Jun 2012 18:04:56 -0300 Received: from livre.localdomain (aoliva@localhost.localdomain [127.0.0.1]) by livre.localdomain (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q5QL4tot005384; Tue, 26 Jun 2012 18:04:55 -0300 Received: (from aoliva@localhost) by livre.localdomain (8.14.3/8.14.3/Submit) id q5QL4sk8005380; Tue, 26 Jun 2012 18:04:54 -0300 From: Alexandre Oliva To: gcc-patches@gcc.gnu.org Subject: [testsuite] don't use lto plugin if it doesn't work Date: Tue, 26 Jun 2012 18:04:54 -0300 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 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 I test i686-linux-gnu in a presumably unusual setting: it's an x86_64-linux-gnu system, and I've configured the GCC build to use as builddev tools wrapper scripts for as, ld, gnatmake and gcc that add flags that make them default to 32-bit. This worked fine for regression testing, but I've recently realized (with the PR49888/53671 mishap) that I'm getting tons of LTO testsuite failures (before and after, so no regression), because the 32-bit LTO plugin built in this setting can't possibly be used by the 64-bit linker installed on the system. Obviously, passing -melf_i386 to the linker through the wrapper is not enough for it to be able to dlopen a 32-bit plugin ;-) I'm considering installing alternate 32-bit tools on my system for better testing, but I figured I'd betetr fix the test harness before tackling this: if we find that the LTO plugin doesn't work, we'd better not use -flto without -fno-use-linker-plugin, to avoid such spurious failures as GCC attempts by its own initiative to use the linker plugin. At first I wished there was a simpler, off-band way to tell it not to use the LTO plugin, that didn't pollute the command line or the test results, but before I even looked around for some such way, I figured it would be useful to have information that the linker plugin was not used in a particular test run, so I went for this patch instead. Ok to install? for gcc/testsuite/ChangeLog from Alexandre Oliva * lib/c-torture.exp (LTO_TORTURE_OPTIONS): Add -fno-use-linker-plugin if plugin detection does not succeed. * lib/gcc-dg.exp (LTO_TORTURE_OPTIONS): Likewise. * lib/lto.exp (LTO_OPTIONS): Likewise. Index: gcc/testsuite/lib/c-torture.exp =================================================================== --- gcc/testsuite/lib/c-torture.exp.orig 2012-06-25 19:15:07.490911571 -0300 +++ gcc/testsuite/lib/c-torture.exp 2012-06-25 19:15:32.927836277 -0300 @@ -61,8 +61,8 @@ if [check_effective_target_lto] { ] } else { set LTO_TORTURE_OPTIONS [list \ - { -O2 -flto -flto-partition=none } \ - { -O2 -flto } + { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \ + { -O2 -flto -fno-use-linker-plugin } ] } } Index: gcc/testsuite/lib/gcc-dg.exp =================================================================== --- gcc/testsuite/lib/gcc-dg.exp.orig 2012-06-25 19:15:09.617738045 -0300 +++ gcc/testsuite/lib/gcc-dg.exp 2012-06-25 19:15:33.161817189 -0300 @@ -92,8 +92,8 @@ if [check_effective_target_lto] { set gcc_force_conventional_output "-ffat-lto-objects" } else { set LTO_TORTURE_OPTIONS [list \ - { -O2 -flto -flto-partition=none } \ - { -O2 -flto } + { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \ + { -O2 -flto -fno-use-linker-plugin } ] } } Index: gcc/testsuite/lib/lto.exp =================================================================== --- gcc/testsuite/lib/lto.exp.orig 2012-06-25 19:15:14.617330140 -0300 +++ gcc/testsuite/lib/lto.exp 2012-06-25 19:15:34.966669945 -0300 @@ -77,12 +77,12 @@ proc lto_init { args } { ] } else { set LTO_OPTIONS [list \ - {-O0 -flto -flto-partition=none } \ - {-O2 -flto -flto-partition=none } \ - {-O0 -flto -flto-partition=1to1 } \ - {-O2 -flto -flto-partition=1to1 } \ - {-O0 -flto } \ - {-O2 -flto} \ + {-O0 -flto -fno-use-linker-plugin -flto-partition=none } \ + {-O2 -flto -fno-use-linker-plugin -flto-partition=none } \ + {-O0 -flto -fno-use-linker-plugin -flto-partition=1to1 } \ + {-O2 -flto -fno-use-linker-plugin -flto-partition=1to1 } \ + {-O0 -flto -fno-use-linker-plugin } \ + {-O2 -flto -fno-use-linker-plugin } \ ] } }