From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45478 invoked by alias); 8 Mar 2019 22:00:37 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 45355 invoked by uid 89); 8 Mar 2019 22:00:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:CAH6eHd, H*i:sk:CAH6eHd, H*f:y2B-rmp, H*i:w0d X-HELO: mail-wm1-f44.google.com Received: from mail-wm1-f44.google.com (HELO mail-wm1-f44.google.com) (209.85.128.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Mar 2019 22:00:25 +0000 Received: by mail-wm1-f44.google.com with SMTP id e74so13834745wmg.3 for ; Fri, 08 Mar 2019 14:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hUfl2j7JtWCwHH2smB4KmnPcVZhd6vYkcT4WQjekcNQ=; b=EdbX8HoOM+DY7GfkbHszzaba0fFqK4MKnN+XvMA7aTcfFjFrM6+0SAbxbJ216+GcNG k2uE7TN6kPPiPa2YDGOFY4sPEUfazGZYn1lVj6vktq4cQUka7pelxAh9bxhjNWNZEGwH 3vHG7Q2zuWP8RpiXkmYycYVaXU1MF4YKB4Q2Wf8RoQdW9hwJpZYPneveiCea95U8MAN5 2SHmFwqL0KAYz99wvFhyGiRdIDsryXCU5p7TxYuWUyFC09MydNeqXEz0gaS+P8xEv4SZ oixchhyq+XzZfot7XgUVkxbrpN1d8s/rmyjW8L+W7wapdYhDUAB7GqxhPJgZf0dETmm9 fdAA== MIME-Version: 1.0 References: In-Reply-To: From: Vanida Plamondon Date: Fri, 08 Mar 2019 22:00:00 -0000 Message-ID: Subject: Re: Ryzen PPA znver1 optimizations To: Jonathan Wakely Cc: GCC Development Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00057.txt.bz2 OK, so it seems I need to give more information to clarify what I am trying to do. I am not invoking or configuring gcc directly. I am creating debian source code packages which are then dispatched to launchpad.net, which then automatically compiles and builds my package based on the debian configuration files. I am trying to created a toolchain that does this automatically while also setting the znver1 optimisations automatically. As far as I can tell, the --with-arch= and --with-cpu= gcc configuration options set defaults, and do not enforce compilation with these options if a package specifically configures a different cpu or architecture, so correct me if I am wrong. Regardless, I do have those options set in the various versions of gcc in my toolchain, but I need gcc to ignore rogue packages that configure to a different x86 architecture. My PPAs only target znver1 for x86 code, so nothing breaks if my toolchain ignores other x86 architectures. Since I am trying to create an automatic toolchain, it would be much easier to have a gcc that ignores non-default x86 configuration options then it is to try to create a script that finds, catches, and corrects an upstream package that uses a non-default configuration. If the --with-arch= and --with-cpu= gcc configuration options cause gcc to ignore non-default configure options, then please, let me know. Otherwise, I would like someone to tell me if my proposed modification will work as I expect, and If someone has a better way, I need an explanation so I know if the proposed solution is going to work the way I want. On Fri, Mar 8, 2019 at 1:58 PM Jonathan Wakely wrote: > > On Fri, 8 Mar 2019 at 11:28, Vanida Plamondon > wrote: > > > > I realise that, however, debian packages seem to use multiple build > > systems (automake, dh_automake, ninja, etc.), and have no standard > > (that is adhered to), for setting up each build environment. > > Additionally, some packages seem to throw their build configuration > > setup throughout multiple files that are difficult to pin down, and > > usually have little documentation. I am trying to set up a toolchain > > that automatically fetches upstream sources when updated, updates the > > changelog to reflect that the package is znver1 optimised, and > > automatically compiles the package with the znver1 optimisations. Even > > worse, many packages use different environmental variables, and some > > even unset some of such standard variables. > > > > This means I need to setup gcc so that any x86 code thrown at it is > > automatically compiled with znver1 optimisations to overcome these > > limitations. > > That's what the configure options Richi showed will do. > > N.B. he didn't say to use -march=znver1 when compiling with GCC, he > said to use --with-arch=znver1 when configuring GCC itself.