From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118315 invoked by alias); 8 Mar 2019 22:59:16 -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 118304 invoked by uid 89); 8 Mar 2019 22:59:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=jwakelygccgmailcom, jwakely.gcc@gmail.com, terminology, H*i:sk:nyo4rYQ X-HELO: mail-wr1-f42.google.com Received: from mail-wr1-f42.google.com (HELO mail-wr1-f42.google.com) (209.85.221.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Mar 2019 22:59:14 +0000 Received: by mail-wr1-f42.google.com with SMTP id w6so22990754wrs.4 for ; Fri, 08 Mar 2019 14:59:13 -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=OGIrOC1i6WhKsXmvqPTBZO4L8zrIKWnDQn71s8T8XXM=; b=qURLhg1jNB1BFCyQlINKGrkFxvDn7ApMhess69G4i3GOUW8GX3wjS/2Tvd6bXLdQAR 1+aM8oBvavD3UgUFQRO1Z5p1Jn6+pdNQiTiDDoNDb3sqG+F/F+vuTN/r2Xkwof7WInOt cRECGBKd9pwf/dI1tXP3TyuaGFBEBBVVmSE3RrvwLxWrtqr0mfWXzdrIoHYnrAagrSiJ qzA0a+t03dWsLJHRqfHZdGGpX5tAvL1D7dGSsn0SzGalDFndRfyjKlUnpBNTDPeMOmwF 48cJf4f6CaGhLVagh2wFbeCS4BjmLrd8d1y0XafsbH9N6zgiX3p3myTqJXi/dfmEKDO8 OPiQ== MIME-Version: 1.0 References: In-Reply-To: From: Vanida Plamondon Date: Fri, 08 Mar 2019 22:59: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/msg00061.txt.bz2 Correct. It's hard to nail down the right terminology when I'm learning by doing. I want GCC to ignore x86 flags that aren't znver1, and keep znver1 as the default. On Fri, Mar 8, 2019, 3:44 PM Jonathan Wakely wrote: > On Fri, 8 Mar 2019 at 22:00, Vanida Plamondon > wrote: > > > > 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. > > (If you're creating a toolchain then surely you're configuring GCC.) > > > 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. > > If by "configures a different cpu or architecture" you mean "uses the > -march option when invoking GCC" then you're correct. > > Using --with-arch=znver1 will make GCC automatically select that > architecture. But it won't prevent that automatic selection being > overridden by an explicit -march option. > > > > 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. > > Yes, that does seem simpler. > > > If the --with-arch= and --with-cpu= gcc configuration options cause > > gcc to ignore non-default configure options, then please, let me know. > > I find this use of "configure options" confusing too. You're talking > about flags passed to GCC when invoking it, not "configure options", > right? >