From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82053 invoked by alias); 13 Jun 2017 09:40:25 -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 80956 invoked by uid 89); 13 Jun 2017 09:40:24 -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=LAST, kick 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; Tue, 13 Jun 2017 09:40:18 +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 336961596; Tue, 13 Jun 2017 02:40:21 -0700 (PDT) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6DA593F581; Tue, 13 Jun 2017 02:40:20 -0700 (PDT) Subject: Re: [PATCH 00/30] [ARM] Reworking the -mcpu, -march and -mfpu options From: "Richard Earnshaw (lists)" To: Joseph Myers Cc: Christophe Lyon , "gcc-patches@gcc.gnu.org" References: <4cae29b4-c6f2-7831-8143-22c4bb0d7a1d@arm.com> <72966d49-38bf-c007-06d0-592af94d9009@arm.com> <3ce93fc1-1c2e-8a6e-2242-a30d314bfa0d@arm.com> Message-ID: <2f9948f1-314a-48b9-2e2f-29916701eaf4@arm.com> Date: Tue, 13 Jun 2017 09:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <3ce93fc1-1c2e-8a6e-2242-a30d314bfa0d@arm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00877.txt.bz2 On 12/06/17 22:27, Richard Earnshaw (lists) wrote: > In fact I probably don't need the % realized that is was possible to maintain all such options and just > interpret the last one. So for my purposes that might be the best > solution, since my canon_arch generated option will simply override any > existing -march options. It turns out this won't work. The multilib selection machinery looks at all the -march= options to make its decision and it is completely unaware of the fact that only the last one is relevant. This was broken before my changes, but the consequences are more severe now. I wonder if we should/could add a LAST attribute to the options specification such that the driver discards all but the final instance of such an option. This would also solve the -mcpu=native problem since the discard rule would kick in and eliminate that option if it wasn't the final one in the list. We clearly can't apply that to every option, since for example -ffixed= needs to accumulate, as do options such as -I; but others are clearly overrides. R.