From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117184 invoked by alias); 28 Apr 2016 15:31:48 -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 116114 invoked by uid 89); 28 Apr 2016 15:31:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 spammy=burgess, Burgess X-HELO: mailrelay2.public.one.com Received: from mailrelay2.public.one.com (HELO mailrelay2.public.one.com) (91.198.169.125) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 28 Apr 2016 15:31:34 +0000 X-HalOne-Cookie: 1a44e2c9c82a04be60577b7e78e27197fe47718e X-HalOne-ID: 469b123f-0d56-11e6-8278-b82a72d03b9b Received: from localhost.localdomain (unknown [91.135.11.213]) by smtpfilter2.public.one.com (Halon Mail Gateway) with ESMTPSA; Thu, 28 Apr 2016 15:31:27 +0000 (UTC) Subject: Re: [PATCHv2 0/7] ARC: Add support for nps400 variant To: Andrew Burgess , gcc-patches@gcc.gnu.org References: Cc: noamca@mellanox.com, Claudiu.Zissulescu@synopsys.com From: Joern Wolfgang Rennecke Message-ID: <57222CCF.1090109@amylaar.uk> Date: Thu, 28 Apr 2016 15:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg01851.txt.bz2 On 21/04/16 12:39, Andrew Burgess wrote: > This new iteration of the previous version is largely the same except > that I now no longer use configure time options to build in support > for nps400. Instead support controlled with a -mcpu=nps400 command > line switch. This change was made to mirror a similar change that was > requested when I pushed nps400 support upstream into binutils. The considerations for these toolchain components are different; it costs little to have do a build with support for an entire architecture with various variants in binutils. gcc having run-time options to generate code for a subtarget is also useful. However, setting defaults and multilib sets at gcc configure time is also quite useful, as otherwise every user is confronted with building multilibs for a burgeoning array of variants.