Hi There, I think for AArch32 mapping it back to armv8-a sounds sufficient. Unless we have string or math routines in newlib that make use of any ACLE guards that are beyond armv8-a …
Ramana From: Richard Earnshaw <richard.earns...@foss.arm.com> Date: Tuesday, 16 November 2021 at 11:48 To: Christophe Lyon <christophe.lyon....@gmail.com>, Przemyslaw Wirkus <przemyslaw.wir...@arm.com> Cc: Ramana Radhakrishnan <ramana.radhakrish...@arm.com>, gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org>, Richard Earnshaw <richard.earns...@arm.com> Subject: Re: [PATCH][GCC] arm: add armv9-a architecture to -march You can't make an omelette without breaking eggs, as they say. New architectures need new assemblers. However, I wonder if there's anything in v9-a that significantly affects the quality of the base multilib code needed for building the libraries. It might be that we can deal with v9-a by just mapping it to the v8-a equivalents. That would then avoid the need for an updated assembler, and reduce the build time and install footprint. R. On 16/11/2021 08:03, Christophe Lyon via Gcc-patches wrote: > Hi, > > > On Tue, Nov 9, 2021 at 12:36 PM Przemyslaw Wirkus via Gcc-patches < > gcc-patches@gcc.gnu.org> wrote: > >>>>> -----Original Message----- >>>>> From: Przemyslaw Wirkus >>>>> Sent: 18 October 2021 10:37 >>>>> To: gcc-patches@gcc.gnu.org >>>>> Cc: Richard Earnshaw <richard.earns...@arm.com>; Ramana >>>>> Radhakrishnan <ramana.radhakrish...@arm.com>; Kyrylo Tkachov >>>>> <kyrylo.tkac...@arm.com>; ni...@redhat.com >>>>> Subject: [PATCH][GCC] arm: add armv9-a architecture to -march >>>>> >>>>> Hi, >>>>> >>>>> This patch is adding `armv9-a` to -march in Arm GCC. >>>>> >>>>> In this patch: >>>>> + Add `armv9-a` to -march. >>>>> + Update multilib with armv9-a and armv9-a+simd. >>>>> >>>>> After this patch three additional multilib directories are available: >>>>> >>>>> $ arm-none-eabi-gcc --print-multi-lib .; [...vanilla multi-lib >>>>> dirs...] thumb/v9-a/nofp;@mthumb@march=armv9-a@mfloat-abi=soft >>>>> thumb/v9-a+simd/softfp;@mthumb@march=armv9-a+simd@mfloat- >>>>> abi=softfp >>>>> thumb/v9-a+simd/hard;@mthumb@march=armv9-a+simd@mfloat- >>>>> abi=hard >>>>> >> > > This is causing a GCC build failure when using "old" binutils (I'm using > 2.36.1), > because the new -march=armv9-a option is not supported. This breaks the > multilib support. > > I don't remember how we handled similar cases in the past? Is that just > "expected", and > "current" GCC needs "current" binutils, or should we have a multilib list > dependent on > the actual binutils support? (I think this is not the case, and it sounds > like an undesirable > extra complication in an already overcrowded mutilib-Makefile) > > Christophe > >>>> New multi-lib directories under >>>>> $GCC_INSTALL_DIE/lib/gcc/arm-none-eabi/12.0.0/thumb are created: >>>>> >>>>> thumb/ >>>>> +--- v9-a >>>>> | |--- nofp >>>>> | >>>>> +--- v9-a+simd >>>>> |--- hard >>>>> |--- softfp >>>>> >>>>> Regtested on arm-none-eabi cross and no issues. >>>>> >>>>> OK for master? >> >> Thanks. >> >> commit 32ba7860ccaddd5219e6dae94a3d0653e124c9dd >> >>> Ok. >>> Thanks, >>> Kyrill >>> >>> >>>>> >>>>> gcc/ChangeLog: >>>>> >>>>> * config/arm/arm-cpus.in (armv9): New define. >>>>> (ARMv9a): New group. >>>>> (armv9-a): New arch definition. >>>>> * config/arm/arm-tables.opt: Regenerate. >>>>> * config/arm/arm.h (BASE_ARCH_9A): New arch enum value. >>>>> * config/arm/t-aprofile: Added armv9-a and armv9+simd. >>>>> * config/arm/t-arm-elf: Added arm9-a, v9_fps and all_v9_archs >>>>> to MULTILIB_MATCHES. >>>>> * config/arm/t-multilib: Added v9_a_nosimd_variants and >>>>> v9_a_simd_variants to MULTILIB_MATCHES. >>>>> * doc/invoke.texi: Update docs. >>>>> >>>>> gcc/testsuite/ChangeLog: >>>>> >>>>> * gcc.target/arm/multilib.exp: Update test with armv9-a entries. >>>>> * lib/target-supports.exp (v9a): Add new armflag. >>>>> (__ARM_ARCH_9A__): Add new armdef. >>>>> >>>>> -- >>>>> kind regards, >>>>> Przemyslaw Wirkus >> >>
