From patchwork Sat Nov 19 21:59:27 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 696962 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3tLpgm1cTTz9ssP for ; Sun, 20 Nov 2016 09:00:03 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Cqo+GH+J"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=iEJr6jgv8WIY7teIo ISTDt+brmPEYxDyj1XJnO3Me9HVPIGwznDLZ/2OWNmZFmjkqX6amKrUxGSeP0M9S BQBPrDaiSbn+StZ5T9QllBbpiY/hQoReAjS3aBdlaCgwaqLo6x0opdopJtbTxZgX OoIDiXapFuDre2PkMbqfu90cnA= 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:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=Xx9MpX3vXPEN+yaNwFZ3jn/ qa6o=; b=Cqo+GH+JfopLEifEeC2zQUOUU1oZXkMCeYZZFnQpzNXlJ6o9Oq8+EnI tiqsG/zcHJEPYsCz9rMW5U65PHILaTQXo7qw0UB0IFoQGMt7v/Z5871OcyGq72IV v4O2bNGsUSLE8n7vteZNViMsfvpstHDMM+tlOUukabZvfDFqwbhY= Received: (qmail 123704 invoked by alias); 19 Nov 2016 21:59:54 -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 123691 invoked by uid 89); 19 Nov 2016 21:59:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=no version=3.3.2 spammy=tighten, Tighten X-HELO: mail-wj0-f173.google.com Received: from mail-wj0-f173.google.com (HELO mail-wj0-f173.google.com) (209.85.210.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 19 Nov 2016 21:59:43 +0000 Received: by mail-wj0-f173.google.com with SMTP id qp4so10769886wjc.3 for ; Sat, 19 Nov 2016 13:59:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KE/Y4imvAaQIiveTF3olBwZf1vkJ79Cvigb2EUlMS/U=; b=A9mmPZ8X2A+y4B4m0bCPZ3Cv5iMKXAZqEkzARzJzitgP+yq79Jw4C1ieUOeAQS/FOW vckvBNr1Fwm+uW4JUBH+OpUFowwwMRFMn+u5RsthPNlem8tWfpXTMNjcitbazq877hLT QrjFbOKHRhA53yuTbcz6iRlX7XuE5IuRwZYZ9rIyhyZnDpUGwaDDvUKrQcpsygW438mV vucrzGVuJTgbJljBUqlu3/3XJCa7/DGLovNXK91j2UmpQBYjtYfgQjrr2pIjKo+154Ho wNBf4yf5KWP75ND5MQ7BD7d5pucW7CWYKs+Kgn0roEemGmXm2o7s60AIQSvmx520EXnN bLuA== X-Gm-Message-State: AKaTC00fpr+xS1A4PQWO9Qrn8qtoU+R7ng+8BhLit9iEmYHbqPo8ACHQWI1eVEoFwltwmg== X-Received: by 10.194.175.163 with SMTP id cb3mr4027616wjc.174.1479592781164; Sat, 19 Nov 2016 13:59:41 -0800 (PST) Received: from localhost (host86-165-30-23.range86-165.btcentralplus.com. [86.165.30.23]) by smtp.gmail.com with ESMTPSA id xu5sm16151427wjc.49.2016.11.19.13.59.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Nov 2016 13:59:39 -0800 (PST) Date: Sat, 19 Nov 2016 21:59:27 +0000 From: Andrew Burgess To: Christophe Lyon Cc: Mike Stump , Bernd Schmidt , "gcc-patches@gcc.gnu.org" , Jeff Law , Jakub Jelinek Subject: Re: Ping: Re: [PATCH 1/2] gcc: Remove unneeded global flag. Message-ID: <20161119215926.GX5975@embecosm.com> References: <512a967c-39c4-44f5-6f24-d75ef543979d@redhat.com> <20160629192130.GF8823@embecosm.com> <20160914130048.GC31794@embecosm.com> <03bef940-2b86-af7d-d2d2-b96b8283596f@redhat.com> <20161116200930.GG5975@embecosm.com> <20161116221217.GH5975@embecosm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.6.1 (2016-04-27) X-IsSubscribed: yes * Christophe Lyon [2016-11-18 13:21:50 +0100]: > On 16 November 2016 at 23:12, Andrew Burgess > wrote: > > * Mike Stump [2016-11-16 12:59:53 -0800]: > > > >> On Nov 16, 2016, at 12:09 PM, Andrew Burgess wrote: > >> > My only remaining concern is the new tests, I've tried to restrict > >> > them to targets that I suspect they'll pass on with: > >> > > >> > /* { dg-final-use { scan-assembler "\.section\[\t \]*\.text\.unlikely\[\\n\\r\]+\[\t \]*\.size\[\t \]*foo\.cold\.0" { target *-*-linux* *-*-gnu* } } } */ > >> > > >> > but I'm still nervous that I'm going to introduce test failures. Is > >> > there any advice / guidance I should follow before I commit, or are > >> > folk pretty relaxed so long as I've made a reasonable effort? > >> > >> So, if you are worried about the way the line is constructed, I usually test it by misspelling the *-*-linux* *-*-gnu* part as *-*-linNOTux* *-*-gnNOTu* and see if the test then doesn't run on your machine. If it doesn't then you can be pretty confident that only machines that match the target triplet can be impacted. I usually do this type of testing by running the test case in isolation (not the full tests suite). Anyway, do the best you can, and don't worry about t it too much, learn from the experience, even if it goes wrong in some way. If it did go wrong, just be responsive (don't check it in just before a 6 week vacation) about fixing it, if you can. > >> > > > > Thanks for the feedback. > > > > Change committed as revision 242519. If anyone sees any issues just > > let me know. > > > > Hi Andrew, > > Sorry for the delay, there are so many commits these days, with so > many regression > reports to check manually before reporting here.... > > So, your new test fails on arm* targets: After a little digging I think the problem might be that -freorder-blocks-and-partition is not supported on arm. This should be detected as the new tests include: /* { dg-require-effective-target freorder } */ however this test passed on arm as -freorder-blocks-and-partition does not issue any warning unless -fprofile-use is also passed. The patch below extends check_effective_target_freorder to check using -fprofile-use. With this change in place the tests are skipped on arm. All feedback welcome, Thanks, Andrew --- arm/gcc: Tighten checks in check_effective_target_freorder In check_effective_target_freorder we check to see if the target supports -freorder-blocks-and-partition. However we disable -freorder-blocks-and-partition when -fprofile-use is not supplied so for some targets we'll not see any message about lack of support for -freorder-blocks-and-partition unless -fprofile-use is also passed. This commit extends check_effective_target_freorder to first try -freorder-blocks-and-partition on its own, then try -fprofile-use and -freorder-blocks-and-partition. gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_freorder): Check additional case. --- gcc/testsuite/ChangeLog | 5 +++++ gcc/testsuite/lib/target-supports.exp | 8 +++++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index 8a2abd2..0716792 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -1014,9 +1014,15 @@ proc check_effective_target_fstack_protector {} { # for trivial code, 0 otherwise. proc check_effective_target_freorder {} { - return [check_no_compiler_messages freorder object { + if { [check_no_compiler_messages freorder object { void foo (void) { } } "-freorder-blocks-and-partition"] + && [check_no_compiler_messages fprofile_use_freorder object { + void foo (void) { } + } "-fprofile-use -freorder-blocks-and-partition"] } { + return 1 + } + return 0 } # Return 1 if -fpic and -fPIC are supported, as in no warnings or errors