From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9656 invoked by alias); 9 Jun 2017 22:45:51 -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 9637 invoked by uid 89); 9 Jun 2017 22:45:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-vk0-f53.google.com Received: from mail-vk0-f53.google.com (HELO mail-vk0-f53.google.com) (209.85.213.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Jun 2017 22:45:48 +0000 Received: by mail-vk0-f53.google.com with SMTP id g66so33077467vki.1 for ; Fri, 09 Jun 2017 15:45:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pDnMwY2pDqRp+sPc44wSQQo7AZaiVf1h/P2HZht4LMs=; b=NW6wAMO/AoSPfi8d2TrzDU84rLz6JXzaH5DZilqHsAHgtRoDOSCsGuKg8HLrr8d/sB uaOBJPEnHpe3kIa5rvZ5gDm3XBJdCprxOa+uK6CTfHH8vP0Ou8VHtnfLf2AAXwB8Ztbf NZQnAPpNngapDRGAjJiOs1XGx4Ck5WBLdwQ5/qQIFrMZo4vSQPilcR7ouIXWttJtl/fp qeyrXfCP5oyT7BPoo4xSBW0ukjRabAdZMQyLU99nwop2gw7U+03+9KnhdQEGGBnaS/hI I1/zhateCCCA6blegh6f69PSqP74PE5E8UpE4FcnO0PjtR/RJqUfsrzCiHnXer7Fp2QT UoWQ== X-Gm-Message-State: AODbwcB6o36aX5JnQEdWsIYbr1qWF/D/gSrVRsfxsIo7PfX1i/r3+9RW GK6jfXl6+6MZ8yX7q5J5hipT2dFnzrf9fqIPzQ== X-Received: by 10.31.165.210 with SMTP id o201mr10221137vke.37.1497048350588; Fri, 09 Jun 2017 15:45:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.50.131 with HTTP; Fri, 9 Jun 2017 15:45:50 -0700 (PDT) In-Reply-To: References: From: Christophe Lyon Date: Fri, 09 Jun 2017 22:45:00 -0000 Message-ID: Subject: Re: [PATCH 00/30] [ARM] Reworking the -mcpu, -march and -mfpu options To: Richard Earnshaw Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00689.txt.bz2 Hi Richard, On 9 June 2017 at 14:53, Richard Earnshaw wrote: > > During the ARM BoF at the Cauldron last year I mentioned that I wanted > to rework the way GCC on ARM handles the command line options. The > problem was that most users, and even many experts, can't remember > which FPU/SIMD unit comes with which CPU and that consequently many > users were inadvertenly generating sub-optimal code for their system. > > This patch series implements the proposed change and provides support > for a generic way of adding optional features to architectures and CPU > names. The documentation patches at the end of the series explain the > new syntax, so I won't repeat all that here. Suffice to say here that > the result is that the -mfpu option now defaults to 'auto', which > allows the compiler to infer the floating-point and simd options from > the CPU/architecture options and that these options can normally be > expressed in a context-specific manner like +simd or +fp without > having to know precisely which variant is implemented. Long term I'd > like to deprecate -mfpu and entirely move over to the new syntax; but > it's too early to start that process now. > > All the patches in the series should build a working basic compiler, > but the multilib selection will not work correctly until the relevant > patches towards the end are applied. It is not really feasible to > retain that functionality without collapsing too many of the patches > together into one hunk. It's also possible that some tests in the > testsuite may exhibit transient misbehaviour, but there should be no > regressions by the end of the sequence (some tests no-longer run in > the default configurations because the default CPU does not have > floating-point support). > > Just two patches are to the generic code, but both are fairly trivial. > One permits the sbitmap code to be used in the driver programs and the > other provides a way of escaping the meta-character in some multilib > reuse strings. > > I won't apply any of this series until those two patches have been > approved, and I won't commit anything before the middle of next week > even then. This is a fairly complex change and it deserves some time > for people to comment before committing. > > R. > > Richard Earnshaw (30): > [arm] Use strings for -march, -mcpu and -mtune options > [arm] Rewrite -march and -mcpu options for passing to the assembler > [arm] Don't pass -mfpu=auto through to the assembler. > [arm] Allow +opt on arbitrary cpu and architecture specifications > [arm] Add architectural options > [arm] Add default FPUs for CPUs. > [build] Make sbitmap code available to the driver programs > [arm] Split CPU, architecture and tuning data tables. > [ARM] Move cpu and architecture option name parsing code to > arm-common.c > [arm] Use standard option parsing code for detecting thumb-only > targets > [arm] Allow CPU and architecture extensions to be defined as aliases > [arm] Allow new extended syntax CPU and architecture names during > configure > [arm] Force a CPU default in the config args defaults list. > [arm] Generate a canonical form for -march > [arm] Make -mfloat-abi=softfp work when there are no FPU instructions > [arm] Update basic multilib configuration > [arm] Make 'auto' the default FPU selection option. > [arm] Rewrite t-aprofile using new selector methodology > [arm] Explicitly set .fpu in cmse_nonsecure_call.S > [genmultilib] Allow explicit periods to be escaped in MULTILIB_REUSE > [arm][testsuite] Use -march=armv7-a+fp when testing hard-float ABI. > [arm] Rewrite t-rmprofile multilib specification > [arm][rtems] Update t-rtems for new option framework > [arm][linux-eabi] Ensure all multilib variables are reset > [arm][phoenix] reset all multilib variables > [arm] Rework multlib builds for symbianelf > [arm][fuchsia] Rework multilib support > [arm] Add a few missing architecture extension options. > [arm][doc] Document new -march= syntax. > [arm][doc] Document changes to -mcpu, -mtune and -mfpu. > > gcc/Makefile.in | 2 +- > gcc/common/config/arm/arm-common.c | 651 +++++++- > gcc/config.gcc | 17 +- > gcc/config/arm/arm-builtins.c | 4 +- > gcc/config/arm/arm-cpu-cdata.h | 2444 +++++++++++++++++++++++------ > gcc/config/arm/arm-cpu-data.h | 1410 ++--------------- > gcc/config/arm/arm-cpu.h | 38 + > gcc/config/arm/arm-cpus.in | 237 ++- > gcc/config/arm/arm-isa.h | 20 +- > gcc/config/arm/arm-protos.h | 56 +- > gcc/config/arm/arm-tables.opt | 21 +- > gcc/config/arm/arm.c | 337 ++-- > gcc/config/arm/arm.h | 75 +- > gcc/config/arm/arm.opt | 15 +- > gcc/config/arm/bpabi.h | 4 - > gcc/config/arm/elf.h | 6 +- > gcc/config/arm/linux-elf.h | 3 - > gcc/config/arm/netbsd-elf.h | 4 - > gcc/config/arm/parsecpu.awk | 295 +++- > gcc/config/arm/t-aprofile | 200 +-- > gcc/config/arm/t-arm-elf | 173 +- > gcc/config/arm/t-fuchsia | 33 + > gcc/config/arm/t-linux-eabi | 4 + > gcc/config/arm/t-multilib | 126 +- > gcc/config/arm/t-phoenix | 20 +- > gcc/config/arm/t-rmprofile | 147 +- > gcc/config/arm/t-rtems | 49 +- > gcc/config/arm/t-symbian | 34 +- > gcc/config/arm/vxworks.h | 2 - > gcc/doc/fragments.texi | 10 +- > gcc/doc/invoke.texi | 371 ++++- > gcc/genmultilib | 4 +- > gcc/testsuite/gcc.dg/pr59418.c | 2 +- > gcc/testsuite/gcc.target/arm/multilib.exp | 685 ++++++++ > gcc/testsuite/gcc.target/arm/pr51915.c | 2 +- > gcc/testsuite/gcc.target/arm/pr52006.c | 2 +- > gcc/testsuite/gcc.target/arm/pr53187.c | 2 +- > libgcc/config/arm/cmse_nonsecure_call.S | 8 + > 38 files changed, 5073 insertions(+), 2440 deletions(-) > create mode 100644 gcc/config/arm/t-fuchsia > create mode 100644 gcc/testsuite/gcc.target/arm/multilib.exp > > ----------------2.7.4-- > I wanted to run a validation with the full series applied as one patch over r249050, so I just downloaded all the patches, concatenated them in order, but the result fails to apply. (conflicts with arm-cpu-cdata.h, arm-cpus.in, t-aprofile, t-rmprofile) Am I missing something? Thanks, Christophe