From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33078 invoked by alias); 12 Jun 2017 21:27:34 -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 32405 invoked by uid 89); 12 Jun 2017 21:27:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=digging, marm X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Jun 2017 21:27:32 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7CEAA344; Mon, 12 Jun 2017 14:27:35 -0700 (PDT) Received: from [192.168.1.19] (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 726AD3F557; Mon, 12 Jun 2017 14:27:34 -0700 (PDT) Subject: Re: [PATCH 00/30] [ARM] Reworking the -mcpu, -march and -mfpu options To: Joseph Myers References: <4cae29b4-c6f2-7831-8143-22c4bb0d7a1d@arm.com> <72966d49-38bf-c007-06d0-592af94d9009@arm.com> Cc: Christophe Lyon , "gcc-patches@gcc.gnu.org" From: "Richard Earnshaw (lists)" Message-ID: <3ce93fc1-1c2e-8a6e-2242-a30d314bfa0d@arm.com> Date: Mon, 12 Jun 2017 21:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00851.txt.bz2 On 12/06/17 18:11, Joseph Myers wrote: > On Mon, 12 Jun 2017, Richard Earnshaw (lists) wrote: > >> It does. The problem seems to be a generic one in the driver in that >> the rewrite rules are always passed the first instance of -march and not >> the last. Indeed, with the aarch64 compiler, if I write >> >> gcc -mcpu=native -mcpu=cortex-a53 >> >> then the driver will rewrite this as >> >> ./cc1 -mcpu=cortex-a53 -mcpu= >> >> which doesn't seem to be the right thing at all. >> >> So we either have a generic problem with all option rewriting, or there >> are some subtle details of it that we've not figured out yet. >> >> Joseph, is there a way to get the rewrite rules to receive the *last* >> instance of a flag rather than the first? Or is the current behaviour >> simply wrong? > > I think there are at least two separate issues here. > > In the AArch64 port (and other ports), the specs for -mcpu=native use > %{mcpu=native:% DRIVER_SELF_SPECS. Options added by DRIVER_SELF_SPECS are added at the > end of the command line (after OPTION_DEFAULT_SPECS has been processed). > Thus, if there is any -mcpu=native option, the options from generated by > local_cpu_detect will be added. > Yes, this seems like a bug in all implementations of native detect routines. To make the behaviour sane I think they will all need to be reworked to pass all relevant -m= variants into some code that checks first that "native" is the last option and only then to apply the substitution. > In patch 14 of this series, you have specs of the form %{mcpu=*: cpu %*} > inside a canon_arch call. According to the comment in gcc.c documenting > specs > > %{S*:X} substitutes X if one or more switches whose names start > with -S was given to GCC. Normally X is substituted only > once, no matter how many such switches appeared. However, > if %* appears somewhere in X, then X will be substituted > once for each matching switch, with the %* replaced by the > part of that switch that matched the '*'. A space will be > appended after the last substition unless there is more > text in current sequence. > > this ought to mean that every -mcpu= option results in a corresponding cpu > in the arguments to canon_arch (in the same order as the > original options). If it doesn't, that sounds like a bug in the %* > handling. > So when I investigated this further this afternoon I made the following observations. Firstly, sometimes all the -march options were being passed through and sometimes only the first. That seemed odd, so I dug a bit further. It seems the later options are cancelled by the % Overridden options can be removed before specs processing if a cycle of > options is marked with Negative in the .opt files (see prune_options), but > that doesn't apply to options with arguments. If you had a system for > pruning e.g. all but the last -mcpu= option (for options where it's just > the last argument that matters), you'd also want to make sure that prior > options do still generate errors if the option argument is invalid. > R.