Re: [PATCH 1/12] arm: Make mbranch-protection opts parsing common to AArch32/64

On 28/04/2022 10:08, Andrea Corallo via Gcc-patches wrote: Hi all, This change refactors all the mbranch-protection option parsing code and types to make it common to both AArch32 and AArch64 backends. This change also pulls in some supporting types from AArch64 to make it common (aarch_pars

Re: [PATCH 2/12] arm: Add Armv8.1-M Mainline target feature +pacbti

On 28/04/2022 10:37, Andrea Corallo via Gcc-patches wrote: This patch adds the -march feature +pacbti to Armv8.1-M Mainline. This feature enables pointer signing and authentication instructions on M-class architectures. Pre-approved here

Re: [PATCH 3/12] arm: Add option -mbranch-protection

On 28/04/2022 10:38, Andrea Corallo via Gcc-patches wrote: [PATCH 3/12] arm: Add option -mbranch-protection Add -mbranch-protection option. This option enables the code-generation of pointer signing and authentication instructions in function prologues and epilogues. gcc/ChangeLog:

Re: [PATCH 4/12] arm: Add testsuite library support for PACBTI target

On 28/04/2022 10:40, Andrea Corallo via Gcc-patches wrote: Add targeting-checking entities for PACBTI in testsuite framework. Pre-approved with the requested changes here . gcc/testsuite/ChangeLog: * testsuite/lib/

Re: [PATCH 4/12] arm: Add testsuite library support for PACBTI target

On 01/07/2022 14:03, Richard Earnshaw via Gcc-patches wrote: On 28/04/2022 10:40, Andrea Corallo via Gcc-patches wrote: Add targeting-checking entities for PACBTI in testsuite framework. Pre-approved with the requested changes here <https://gcc.gnu.org/pipermail/gcc-patches/2021-Decem

Re: [PATCH 5/12] arm: Implement target feature macros for PACBTI

On 28/04/2022 10:42, Andrea Corallo via Gcc-patches wrote: This patch implements target feature macros when PACBTI is enabled through the -march option or -mbranch-protection. The target feature macros __ARM_FEATURE_PAC_DEFAULT and __ARM_FEATURE_BTI_DEFAULT are specified in ARM ACLE

Re: [PATCH 6/12] arm: Add pointer authentication for stack-unwinding runtime

On 28/04/2022 10:44, Andrea Corallo via Gcc-patches wrote: This patch adds authentication for when the stack is unwound when an exception is taken. All the changes here are done to the runtime code in libgcc's unwinder code for Arm target. All the changes are guarded under defined (__ARM_FEAT

Re: [PATCH 7/12] arm: Emit build attributes for PACBTI target feature

On 28/04/2022 10:45, Andrea Corallo via Gcc-patches wrote: This patch emits assembler directives for PACBTI build attributes as defined by the ABI. gcc/ChangeLog: * config/arm/arm.c (arm_file_start): Emi

Re: [PATCH 8/12 V2] arm: Introduce multilibs for PACBTI target feature

On 01/06/2022 13:32, Andrea Corallo via Gcc-patches wrote: Hi all, second iteration of the previous patch adding the following new multilibs: thumb/v8.1-m.main+pacbti/mbranch-protection/nofp thumb/v8.1-m.main+pacbti+dp/mbranch-protection/soft thumb/v8.1-m.main+pacbti+dp/mbranch-protection/ha

Re: [PATCH 8/12 V2] arm: Introduce multilibs for PACBTI target feature

On 01/07/2022 15:54, Richard Earnshaw via Gcc-patches wrote: On 01/06/2022 13:32, Andrea Corallo via Gcc-patches wrote: Hi all, second iteration of the previous patch adding the following new multilibs: thumb/v8.1-m.main+pacbti/mbranch-protection/nofp thumb/v8.1-m.main+pacbti+dp/mbranch

Re: [PATCH 9/12] arm: Make libgcc bti compatible

On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote: This change add bti instructions at the beginning of arm specific libgcc hand written assembly routines. 2022-03-31 Andrea Corallo * libgcc/config/arm/crti.S (FUNC_START): Add bti instruction if necessary.

Re: [PATCH 10/12 V2] arm: Implement cortex-M return signing address codegen

On 28/06/2022 10:17, Andrea Corallo via Gcc-patches wrote: Hi all, second version of this patch enabling address return signature and verification based on Armv8.1-M Pointer Authentication [1]. To sign the return address, we use the PAC R12, LR, SP instruction upon function entry. This is s

Re: [PATCH 11/12] aarch64: Make bti pass generic so it can be used by the arm backend

On 28/04/2022 10:51, Andrea Corallo via Gcc-patches wrote: Hi all, this patch splits and restructures the aarch64 bti pass code in order to have it usable by the arm backend as well. These changes have no functional impact. Best Regards Andrea gcc/Changelog * config.gcc (aarch

Re: [PATCH 12/12 V2] arm: implement bti injection

On 28/06/2022 10:21, Andrea Corallo via Gcc-patches wrote: Hi all, second iteration of this patch enabling Branch Target Identification Armv8.1-M Mechanism [1]. This is achieved by using the bti pass made common with Aarch64. The pass iterates through the instructions and adds the necessary

Re: [PATCH 3/12 V2] arm: Add option -mbranch-protection

On 04/07/2022 10:27, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw writes: [...] +@item +-mbranch-protection=@var{none}|@var{standard}|@var{pac-ret}[+@var{leaf}][+@var{bti}]|@var{bti}[+@var{pac-ret}[+@var{leaf}]] +@opindex mbranch-protection +Enable branch protection features (arm

Re: [PATCH 4/12] arm: Add testsuite library support for PACBTI target

On 04/07/2022 15:47, Andrea Corallo wrote: Richard Earnshaw writes: On 01/07/2022 14:03, Richard Earnshaw via Gcc-patches wrote: On 28/04/2022 10:40, Andrea Corallo via Gcc-patches wrote: Add targeting-checking entities for PACBTI in testsuite framework. Pre-approved with the requested

Re: [PATCH 5/12 V2] arm: Implement target feature macros for PACBTI

On 12/07/2022 16:45, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw writes: On 28/04/2022 10:42, Andrea Corallo via Gcc-patches wrote: This patch implements target feature macros when PACBTI is enabled through the -march option or -mbranch-protection. The target feature macros __A

Re: [PATCH 7/12 V2] arm: Emit build attributes for PACBTI target feature

On 13/07/2022 09:58, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw writes: On 28/04/2022 10:45, Andrea Corallo via Gcc-patches wrote: This patch emits assembler directives for PACBTI build attributes as defined by the ABI.

Re: [PATCH 8/12 V3] arm: Introduce multilibs for PACBTI target feature

On 21/07/2022 10:04, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw writes: [...] The documentation mentions -mbranch-protection=standard+leaf, so you're missing a mapping for that. OK with that change. R. Oh, and please add some tests to gcc/testsuite/gcc.target/arm/multilib.exp

Re: [PATCH 9/12 V2] arm: Make libgcc bti compatible

On 21/07/2022 10:17, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw writes: On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote: This change add bti instructions at the beginning of arm specific libgcc hand written assembly routines. 2022-03-31 Andrea Corallo * libgcc

Re: [PATCH 9/12 V2] arm: Make libgcc bti compatible

On 22/07/2022 16:09, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw writes: On 21/07/2022 10:17, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw writes: On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote: This change add bti instructions at the beginning of arm sp

Re: [PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM

On 27/07/2022 14:40, herron.philip--- via Gcc-patches wrote: From: Philip Herron This adds the nessecary target hooks for the arm target. gcc/ChangeLog: * config.gcc: add rust_target_objs for arm gcc/config/arm/ChangeLog: * arm-protos.h: define arm_rust_target_cpu_info

http://pdtlreviewboard.cambridge.arm.com/r/16099/

A SET operation that writes memory may have the same value as an earlier store but if the alias sets of the new and earlier store do not conflict then the set is not truly redundant. This can happen, for example, if objects of different types share a stack slot. To fix this we define a new fu

cselib: add function to check if SET is redundant [PR106187]

[resend with correct subject line] A SET operation that writes memory may have the same value as an earlier store but if the alias sets of the new and earlier store do not conflict then the set is not truly redundant. This can happen, for example, if objects of different types share a stack s

Re: cselib: add function to check if SET is redundant [PR106187]

On 29/07/2022 08:06, Richard Biener via Gcc-patches wrote: On Thu, Jul 28, 2022 at 6:46 PM Richard Earnshaw wrote: [resend with correct subject line] A SET operation that writes memory may have the same value as an earlier store but if the alias sets of the new and earlier store do not con

[PATCH v2] cselib: add function to check if SET is redundant [PR106187]

A SET operation that writes memory may have the same value as an earlier store but if the alias sets of the new and earlier store do not conflict then the set is not truly redundant. This can happen, for example, if objects of different types share a stack slot. To fix this we define a new fu

Re: [PATCH v2] cselib: add function to check if SET is redundant [PR106187]

On 30/07/2022 20:57, Jeff Law via Gcc-patches wrote: On 7/29/2022 7:52 AM, Richard Earnshaw via Gcc-patches wrote: A SET operation that writes memory may have the same value as an earlier store but if the alias sets of the new and earlier store do not conflict then the set is not truly

Re: [RFA configure parts] aarch64: Make cc1 &co handle --with options

On 13/06/2022 15:33, Richard Sandiford via Gcc-patches wrote: On aarch64, --with-arch, --with-cpu and --with-tune only have an effect on the driver, so “./xgcc -B./ -O3” can give significantly different results from “./cc1 -O3”. --with-arch did have a limited effect on ./cc1 in previous relea

Re: [PATCH v2] cselib: add function to check if SET is redundant [PR106187]

On 01/08/2022 11:38, Richard Earnshaw via Gcc-patches wrote: On 30/07/2022 20:57, Jeff Law via Gcc-patches wrote: On 7/29/2022 7:52 AM, Richard Earnshaw via Gcc-patches wrote: A SET operation that writes memory may have the same value as an earlier store but if the alias sets of the new

Re: [PATCH v2] cselib: add function to check if SET is redundant [PR106187]

On 03/08/2022 00:36, Jeff Law wrote: On 8/2/2022 10:06 AM, Richard Earnshaw wrote: On 01/08/2022 11:38, Richard Earnshaw via Gcc-patches wrote: On 30/07/2022 20:57, Jeff Law via Gcc-patches wrote: On 7/29/2022 7:52 AM, Richard Earnshaw via Gcc-patches wrote: A SET operation that

Re: [RFA configure parts] aarch64: Make cc1 &co handle --with options

On 05/08/2022 14:53, Richard Sandiford via Gcc-patches wrote: Richard Earnshaw writes: On 13/06/2022 15:33, Richard Sandiford via Gcc-patches wrote: On aarch64, --with-arch, --with-cpu and --with-tune only have an effect on the driver, so “./xgcc -B./ -O3” can give significantly different r

Re: [GCC][PATCH] arm: Add support for Arm Cortex-M85 CPU.

On 05/08/2022 16:20, Srinath Parvathaneni via Gcc-patches wrote: Hi, This patch adds the -mcpu support for the Arm Cortex-M85 CPU which is an Armv8.1-M Mainline CPU supporting MVE and PACBTI by default. -mpcu=cortex-m85 switch by default matches to -march=armv8.1-m.main+pacbti+mve.fp+fp.dp.

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

On 17/02/2023 06:09, Alexandre Oliva via Gcc-patches wrote: On Apr 5, 2022, Alexandre Oliva wrote: Would something like this be acceptable/desirable? It's overreaching, in that not all arm platforms are expected to fail, but the result on them will be an unexpected pass, which is not quite a

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

On 21/02/2023 16:31, Richard Earnshaw via Gcc-patches wrote: On 17/02/2023 06:09, Alexandre Oliva via Gcc-patches wrote: On Apr  5, 2022, Alexandre Oliva wrote: Would something like this be acceptable/desirable?  It's overreaching, in that not all arm platforms are expected to fail

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

On 22/02/2023 19:57, Alexandre Oliva wrote: On Feb 21, 2023, Richard Earnshaw wrote: Rather than scanning for the triplet, a better test would be { xfail { arm_eabi } } Indeed, thanks. Here's the updated patch, retested. Ok to install? Based on Nathan's comments, we should just ski

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

On 23/02/2023 21:20, Alexandre Oliva wrote: On Feb 23, 2023, Alexandre Oliva wrote: On Feb 23, 2023, Richard Earnshaw wrote: On 22/02/2023 19:57, Alexandre Oliva wrote: On Feb 21, 2023, Richard Earnshaw wrote: Rather than scanning for the triplet, a better test would be { xfail { a

Re: [OBVIOUS][PATCH] testsuite, arm: Add -mthumb to pr98931.c [PR target/98931]

On 12/02/2021 14:20, Christophe Lyon via Gcc-patches wrote: > This test forces -march=armv8.1-m.main, which supports only Thumb mode. > However, if the toolchain is not configured --with-thumb, the test > fails with: > error: target CPU does not support ARM mode > > Adding -mthumb to dg-options fi

Re: [OBVIOUS][PATCH] testsuite, arm: Add -mthumb to pr98931.c [PR target/98931]

On 12/02/2021 17:21, Christophe Lyon wrote: > On Fri, 12 Feb 2021 at 17:02, Richard Earnshaw > wrote: >> >> On 12/02/2021 14:20, Christophe Lyon via Gcc-patches wrote: >>> This test forces -march=armv8.1-m.main, which supports only Thumb mode. >>> However, if the toolchain is not configured --with

Re: [[PATCH] 1/3] aarch64: Sanitize access to cfun in aarch64_declare_function_name()

On 09/12/2020 17:21, Christoph Müllner wrote: > From: Christoph Muellner > > It is possible to call aarch64_declare_function_name() and > have cfun not set. Let's sanitize the access to this variable. > > gcc/ > > * config/aarch64/aarch64.c (aarch64_declare_function_name): > Santize acc

Re: [arm/testsuite]: Skip pr97969.c if -mthumb is not compatible [PR target/97969]

On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote: > Ping? > > On Wed, 3 Feb 2021 at 10:01, Christophe Lyon > wrote: >> >> Ping? >> I guess that's obvious enough? >> >> On Wed, 27 Jan 2021 at 10:03, Christophe Lyon >> wrote: >>> >>> Depending on how the toolchain is configured or how t

Re: [arm/testsuite]: Skip pr97969.c if -mthumb is not compatible [PR target/97969]

On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote: > On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote: >> Ping? >> >> On Wed, 3 Feb 2021 at 10:01, Christophe Lyon >> wrote: >>> >>> Ping? >>> I guess that's obvious en

Re: [arm/testsuite]: Skip pr97969.c if -mthumb is not compatible [PR target/97969]

On 02/03/2021 18:10, Christophe Lyon wrote: > On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw > wrote: >> >> On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote: >>> On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote: >>>> Ping? >>>>

Re: [arm/testsuite]: Skip pr97969.c if -mthumb is not compatible [PR target/97969]

On 02/03/2021 18:14, Richard Earnshaw via Gcc-patches wrote: > On 02/03/2021 18:10, Christophe Lyon wrote: >> On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw >> wrote: >>> >>> On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote: >>>> On 01/0

Re: [arm/testsuite]: Skip pr97969.c if -mthumb is not compatible [PR target/97969]

On 02/03/2021 18:35, Christophe Lyon wrote: > On Tue, 2 Mar 2021 at 19:18, Richard Earnshaw > wrote: >> >> On 02/03/2021 18:14, Richard Earnshaw via Gcc-patches wrote: >>> On 02/03/2021 18:10, Christophe Lyon wrote: >>>> On Tue, 2 Mar 2021 at 17:25, Richard

[PATCH 0/3] arm: fix problems when targetting extended FPUs [PR101723]

This patch series addresses an issue that has come to light due to a change in the way GAS handles .fpu directives in the assembler. A fix to the assembler made in binutils 2.34 to clear out all features realated to the FPU when .fpu is emitted has started causing problems for GCC because of the o

[PATCH 1/3] arm: ensure the arch_name is always set for the build target

This should never happen now if GCC is invoked by the driver, but in the unusual case of calling cc1 (or its ilk) directly from the command line the build target's arch_name string can remain NULL. This can complicate later processing meaning that we need to check for this case explicitly in some

[PATCH 2/3] arm: Don't reconfigure globals in arm_configure_build_target

arm_configure_build_target is usually used to reconfigure the arm_active_target structure, which is then used to reconfigure a number of other global variables describing the current target. Occasionally, however, we need to use arm_configure_build_target to construct a temporary target structure

[PATCH 3/3] arm: reorder assembler architecture directives [PR101723]

A change to the way gas interprets the .fpu directive in binutils-2.34 means that issuing .fpu will clear any features set by .arch_extension that apply to the floating point or simd units. This unfortunately causes problems for more recent versions of the architecture because we currently emit .

Re: [PATCH 0/3] arm: fix problems when targetting extended FPUs [PR101723]

On 03/08/2021 16:04, Christophe Lyon via Gcc-patches wrote: On Mon, Aug 2, 2021 at 4:57 PM Richard Earnshaw wrote: This patch series addresses an issue that has come to light due to a change in the way GAS handles .fpu directives in the assembler. A fix to the assembler made in binutils 2.

[committed v2 0/3] arm: fix problems when targetting extended FPUs [PR101723]

Thanks, Christophe, I've updated the testsuite to fix all the issues I could see from your test runs. This is what I've finally committed, but if there's any more fallout, please let me know. R. Richard Earnshaw (3): arm: ensure the arch_name is always set for the build target arm: Don't rec

[committed v2 1/3] arm: ensure the arch_name is always set for the build target

This should never happen now if GCC is invoked by the driver, but in the unusual case of calling cc1 (or its ilk) directly from the command line the build target's arch_name string can remain NULL. This can complicate later processing meaning that we need to check for this case explicitly in some

[committed v2 2/3] arm: Don't reconfigure globals in arm_configure_build_target

arm_configure_build_target is usually used to reconfigure the arm_active_target structure, which is then used to reconfigure a number of other global variables describing the current target. Occasionally, however, we need to use arm_configure_build_target to construct a temporary target structure

[committed v2 3/3] arm: reorder assembler architecture directives [PR101723]

A change to the way gas interprets the .fpu directive in binutils-2.34 means that issuing .fpu will clear any features set by .arch_extension that apply to the floating point or simd units. This unfortunately causes problems for more recent versions of the architecture because we currently emit .

Re: [committed v2 3/3] arm: reorder assembler architecture directives [PR101723]

On 06/08/2021 15:08, Christophe Lyon via Gcc-patches wrote: On Thu, Aug 5, 2021 at 1:58 PM Richard Earnshaw wrote: A change to the way gas interprets the .fpu directive in binutils-2.34 means that issuing .fpu will clear any features set by .arch_extension that apply to the floating point

Re: [committed v2 3/3] arm: reorder assembler architecture directives [PR101723]

On 06/08/2021 15:21, Christophe Lyon via Gcc-patches wrote: On Fri, Aug 6, 2021 at 4:08 PM Christophe Lyon < christophe.lyon@gmail.com> wrote: On Thu, Aug 5, 2021 at 1:58 PM Richard Earnshaw wrote: A change to the way gas interprets the .fpu directive in binutils-2.34 means that is

[committed 2/6] arm: testsuite: improve detection of CMSE hardware.

The test for CMSE support being available in hardware currently relies on the compiler not optimizing away a secure gateway operation. But even that is suspect, because the SG instruction is just a NOP on armv8-m implementations that do not support the security extension. Replace the existing test

[committed 4/6] arm: add erratum mitigation to __gnu_cmse_nonsecure_call [PR102035]

Add the recommended erratum mitigation sequence to __gnu_cmse_nonsecure_call for use on Armv8-m.main devices. Since this is in the library code we cannot know in advance whether the core we are running on will be affected by this, so always enable it. libgcc: PR target/102035 * con

[committed 1/6] arm: Fix general issues with patterns for VLLDM and VLSTM

Both lazy_store_multiple_insn and lazy_load_multiple_insn contain invalid RTL (eg they contain a post_inc statement outside of a mem). What's more, the instructions concerned do not modify their input address register. We probably got away with this because they are generated so late in the compil

[committed 0/6] arm: mitigation for CVE-2021-35465

Arm recently disclosed a security-related erratum (CVE-2021-35465) for some armv8-m and armv8.1-m products relating to use of the VLLDM instruction during the transition from secure to non-secure state. This patch implements the recommended software mitigation for this erratum for use on unfixed s

[committed 5/6] arm: fix vlldm erratum for Armv8.1-m [PR102035]

For Armv8.1-m we generate code that emits VLLDM directly and do not rely on support code in the library, so emit the mitigation directly as well, when required. In this case, we can use the compiler options to determine when to apply the fix and when it is safe to omit it. gcc: PR target/

[committed 6/6] arm: Add tests for VLLDM mitigation [PR102035]

New tests for the erratum mitigation. gcc/testsuite: PR target/102035 * gcc.target/arm/cmse/mainline/8_1m/soft/cmse-13a.c: New test. * gcc.target/arm/cmse/mainline/8_1m/soft/cmse-7a.c: Likewise. * gcc.target/arm/cmse/mainline/8_1m/soft/cmse-8a.c: Likewise. *

[committed 3/6] arm: Add command-line option for enabling CVE-2021-35465 mitigation [PR102035]

Add a new option, -mfix-cmse-cve-2021-35465 and document it. Enable it automatically for cortex-m33, cortex-m35p and cortex-m55. gcc: PR target/102035 * config/arm/arm.opt (mfix-cmse-cve-2021-35465): New option. * doc/invoke.texi (Arm Options): Document it. * confi

Re: [PATCH] arm: Fix multiple inheritance thunks for thumb-1 with -mpure-code

On 29/09/2020 20:50, Christophe Lyon via Gcc-patches wrote: > When mi_delta is > 255 and -mpure-code is used, we cannot load delta > from code memory (like we do without -mpure-code). > > This patch builds the value of mi_delta into r3 with a series of > movs/adds/lsls. > > We also do some cleanu

Re: [PATCH] arm: Fix multiple inheritance thunks for thumb-1 with -mpure-code

On 08/10/2020 10:07, Christophe Lyon via Gcc-patches wrote: > On Tue, 6 Oct 2020 at 18:02, Richard Earnshaw > wrote: >> >> On 29/09/2020 20:50, Christophe Lyon via Gcc-patches wrote: >>> When mi_delta is > 255 and -mpure-code is used, we cannot load delta >>> from code memory (like we do without -

Re: [PATCH v2] testsuite: [arm] Relax expected register names in MVE tests

On 30/09/2022 12:19, Christophe Lyon via Gcc-patches wrote: These two tests have hardcoded q0 as destination/source of load/store instructions, but this register is actually used only under -mfloat-abi=hard. When using -mfloat-abi=softfp, other registers (eg. q3) can be used to transfer functi

Re: [PATCH] arm: Add missing early clobber to MVE vrev64q_m patterns

On 03/10/2022 11:43, Christophe Lyon via Gcc-patches wrote: Like the non-predicated vrev64q patterns, mve_vrev64q_m_ and mve_vrev64q_m_f need an early clobber constraint, otherwise we can generate an unpredictable instruction: Warning: 64-bit element size and same destination and source opera

Re: [PATCH] [testsuite][arm] Fix cmse-15.c expected output

On 23/09/2022 09:43, Torbjörn SVENSSON via Gcc-patches wrote: The cmse-15.c testcase fails at -Os because ICF means that we generate secure3: b secure1 which is OK, but does not match the currently expected secure3: ... bx r[0-3] gcc/testsuite/ChangeLog:

Re: [PATCH] arm: fix option quoting in error messages.

On 07/03/2022 10:27, Martin Liška wrote: This fixes option quoting in error messages. Ready to be installed? Thanks, Martin PR target/104794 gcc/ChangeLog: * config/arm/arm.cc (arm_option_override_internal): Fix quoting of options in error messages. (arm_option_reconfig

[PATCH] contrib: Avoid use of "echo -n" in git customization [PR102664]

The -n option to echo is non-portable. The generally recommended alternative is to use the shell printf command. contrib/ChangeLog: PR other/102664 * gcc-git-customization.sh (ask): Use printf instead of echo -n.diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-cus

Re: [PATCH] contrib: Avoid use of "echo -n" in git customization [PR102664]

On 09/03/2022 15:05, Jonathan Wakely via Gcc-patches wrote: On 09/03/22 12:15 +, Richard Earnshaw wrote: The -n option to echo is non-portable.  The generally recommended alternative is to use the shell printf command. contrib/ChangeLog: PR other/102664 * gcc-git-customization.s

[PATCH 1/2] arm: correctly handle zero-sized bit-fields in AAPCS [PR102024]

On arm the AAPCS states that an HFA is determined by the 'shape' of the object after layout has been completed, so anything that adds no members and does not cause the layout to be modified should be ignored for the purposes of determining which registers are used for parameter passing. A zero-si

[PATCH 2/2] aarch64: correctly handle zero-sized bit-fields in AAPCS64 [PR102024]

On aarch64 the AAPCS64 states that an HFA is determined by the 'shape' of the object after layout has been completed, so anything that adds no members and does not cause the layout to be modified should be ignored for the purposes of determining which registers are used for parameter passing. A z

[committed] arm: temporarily disable 'local' pcs selection (PR96882)

The arm port has an optimization used during selection of the function's ABI to permit deviation from the strict ABI when the function does not escape the current translation unit. Unfortunately, the ABI selection it makes can be unsafe if it changes how a result is returned because not enough in

Re: [PATCH 1/2] arm: correctly handle zero-sized bit-fields in AAPCS [PR102024]

On 29/03/2022 17:32, Jakub Jelinek via Gcc-patches wrote: On Tue, Mar 29, 2022 at 04:32:10PM +0100, Richard Earnshaw wrote: On arm the AAPCS states that an HFA is determined by the 'shape' of the object after layout has been completed, so anything that adds no members and does not cause the

Re: [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796]

Doesn't this need the anchor that the compiler links to? #zero_width_bitfields R. On 30/03/2022 11:07, Jakub Jelinek via Gcc-patches wrote: Hi! This patch documents the PR102024 ABI changes. The x86-64, ARM and AArch64 backends refer to this in their -Wpsabi diagnostics. Ok for wwwdocs? diff

Re: [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796]

Never mind, just spotted it. :) On 30/03/2022 13:10, Richard Earnshaw wrote: Doesn't this need the anchor that the compiler links to? #zero_width_bitfields R. On 30/03/2022 11:07, Jakub Jelinek via Gcc-patches wrote: Hi! This patch documents the PR102024 ABI changes. The x86-64, ARM and

Re: [PATCH] target/102125 - alternative memcpy folding improvement

On 23/03/2022 14:57, Richard Biener via Gcc-patches wrote: The following extends the heuristical memcpy folding path with the ability to use misaligned accesses on strict-alignment targets just like the size-based path does. That avoids regressing the following testcase on arm uint64_t

Re: [PATCH] aarch64: Restrict aarch64-tune.md regeneration to --enable-maintainer-mode [PR105144]

On 04/04/2022 11:49, Jakub Jelinek via Gcc-patches wrote: On Mon, Apr 04, 2022 at 11:10:14AM +0100, Richard Sandiford wrote: Normally updates to the source directory files are guarded with --enable-maintainer-mode, e.g. we don't regenerate configure, config.h, Makefile.in in directories that

Re: [PATCH] aarch64: Restrict aarch64-tune.md regeneration to --enable-maintainer-mode [PR105144]

On 04/04/2022 13:12, Jakub Jelinek via Gcc-patches wrote: On Mon, Apr 04, 2022 at 12:32:27PM +0100, Richard Earnshaw via Gcc-patches wrote: OK. Thanks, now committed. I think we have a similar issue for arm with arm-tune.md and arm-tables.opt. Perhaps we should adopt a similar approach

Re: [PATCH][GCC] arm: remove unnecessary armv9-a multilib variant [PR104144]

On 08/04/2022 15:48, Przemyslaw Wirkus via Gcc-patches wrote: Hi, This patch is removing unnecessary armv9-a multilib variant which was introduced in commit 32ba7860ccaddd5219e6dae94a3d0653e124c9dd (add armv9-a architecture to -march). Now armv9-a(+simd) multilibs point to already existing ar

[pushed] arm: fix testsuite failure of reg_equal_test.c [PR101755]

The test failure in PR101755 is due to the gimple optimizers getting smarter. But really we are just testing that RTL expansion is doing the right thing and annotating a constant accordingly. So rework the test to use GIMPLE input and simplify the code entirely. Also, this test only ever worked

Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ

On 17/01/2022 21:41, Martin Liška wrote: On 1/13/22 12:01, Martin Liška wrote: Hello. Based on the discussion with release managers, the change is going to happen after stage4 begins. Martin Hi. The renaming patches have been just installed and I've built a few target compilers so far

[committed 0/7] Arm: mitigation for AES erratum on Cortex-a57 and Cortex-A72

The Cortex-A57 and Cortex-A72 processors have an erratum (#1742098 and #1655431 respectively) when running in Arm (32-bit) mode where an instruction producing a 32-bit result that feeds into an AES encode or decode can lead to an incorrect result. The erratum does not occur when operating in 64-bi

[PATCH 1/7] arm: Disambiguate multiple crypto patterns with the same name.

No functional change, but arm/crypto.md has multiple pattenrs all called crypto_, which makes references to them ambiguous, so add the iterator base to the pattern name so that it is distinct in the commit logs. gcc/ChangeLog: * config/arm/crypto.md (crypto_): Add iterator to pat

[PATCH 2/7] arm: Consistently use crypto_mode attribute in crypto patterns

A couple of patterns in the crypto support code were hard-coding the mode rather than using the iterators. While not incorrect, it was slightly confusing, so adapt those patterns to the style of the rest of the file. Also fix some white space issues. gcc/ChangeLog: * config/arm/crypto.

[PATCH 3/7] arm: Add option for mitigating against Cortex-A CPU erratum for AES

Add a new option -mfix-cortex-a-aes for enabling the Cortex-A AES erratum work-around and enable it automatically for the affected products (Cortex-A57 and Cortex-A72). gcc/ChangeLog: * config/arm/arm-cpus.in (quirk_aes_1742098): New quirk feature (ALL_QUIRKS): Add it. (c

[PATCH 4/7] arm: add basic mitigation for Cortex-A AES errata

This patch adds the basic patterns for mitigation of the erratum, but no attempt is made at this point to optimize the results for the cases where the erratum mitigation is not needed. The mitigation is done by guaranteeing that the input operands are fed from a full-width operation by using an i

[PATCH 5/7] arm: suppress aes erratum when forwarding from aes

AES operations are commonly chained and since the result of one AES operation is never a 32-bit value, they do not need an additional mitigation instruction for the forwarded result. We handle this common case by adding additional patterns that allow for this. gcc/ChangeLog: * config/ar

[PATCH 6/7] arm: elide some cases where the AES erratum workaround is not required.

Some common cases where the AES erratum workaround are not required are when there are 64- or 128-bit loads from memory, moving a 128-bit value from core registers, and where a 128-bit constant is being loaded from a literal pool. The loads may also be misaligned or generated via a neon intrinsic

[PATCH 7/7] arm: Add test for AES erratum mitigation

Add a testcase for the erratum mitigation. To improve coverage use -dp on the assembler output and match the pattern names (and where needed the alternative number). gcc/testsuite/ChangeLog: * gcc.target/arm/crypto-vaese-erratum1.c: New test. --- .../gcc.target/arm/crypto-vaese-erratum

[PATCH] aarch64: allow ld1/stq in test output [PR102517]

Following the changes to the inline memcpy operations get expanded, we now generate ld1/st1 using a 128-bit vector register rather than ldp with Q registers. The behaviour is equivalent, so relax the tests to permit either variant. gcc/testsuite/ChangeLog: PR target/102517 * gcc

[committed] aarch64: Adjust spellcheck tests for recent quotation-mark changes

Martin's recent change to the way we handle quotation marks and punctuation in error messages caused some fallout in the testsuite. This patch updates the tests for the new output. Adjust tests for quotation-mark and punctuation changes. gcc/testsuite: * gcc.target/aarch64/spellche

Re: [PATCH 1/2][GCC] arm: Move arm_simd_info array declaration into header

On 16/11/2021 10:14, Murray Steele via Gcc-patches wrote: Hi all, This patch moves the arm_simd_type and arm_type_qualifiers enums, and arm_simd_info struct from arm-builtins.c into arm-builtins.h header. This is a first step towards internalising the type definitions for MVE predicate, vect

Re: [PATCH 2/2][GCC] arm: Declare MVE types internally via pragma

On 16/11/2021 10:15, Murray Steele via Gcc-patches wrote: Hi all, This patch moves the implementation of MVE ACLE types from arm_mve_types.h to inside GCC via a new pragma, which replaces the prior type definitions. This allows for the types to be used internally for intrinsic function defini

Re: [PATCH 2/2][GCC] arm: Declare MVE types internally via pragma

On 23/11/2021 09:37, Murray Steele wrote: On 18/11/2021 15:45, Richard Earnshaw wrote: This is mostly OK, but can't we reduce the number of tests somewhat? For example, I think you can merge type_redef_13.c and type_redef_14.c by writing /* { dg-do compile } */ /* { dg-require-effective-t

Re: [PATCH 1/2][GCC] arm: Move arm_simd_info array declaration into header

On 24/11/2021 12:15, Murray Steele wrote: On 18/11/2021 15:40, Richard Earnshaw wrote: On 16/11/2021 10:14, Murray Steele via Gcc-patches wrote: Hi all, This patch moves the arm_simd_type and arm_type_qualifiers enums, and arm_simd_info struct from arm-builtins.c into arm-builtins.h heade

Re: [Patch 1/8, Arm, AArch64, GCC] Refactor mbranch-protection option parsing and make it common to AArch32 and AArch64 backends. [Was RE: [Patch 2/7, Arm, GCC] Add option -mbranch-protection.]

On 10/11/2021 13:55, Andrea Corallo via Gcc-patches wrote: Tejas Belagod via Gcc-patches writes: [...] This change refactors all the mbranch-protection option parsing code and types to make it common to both AArch32 and AArch64 backends. This change also pulls in some supporting types fro

Re: [Patch 1/8, Arm, AArch64, GCC] Refactor mbranch-protection option parsing and make it common to AArch32 and AArch64 backends. [Was RE: [Patch 2/7, Arm, GCC] Add option -mbranch-protection.]

On 30/11/2021 11:11, Andrea Corallo via Gcc-patches wrote: Tejas Belagod via Gcc-patches writes: Ping for this series. Thanks, Tejas. Hi all, pinging this series. BR Andrea It would be easier to find the 'series' if the messages were properly threaded together... R.

Re: [Patch 2/8, Arm, GCC] Add Armv8.1-M Mainline target feature +pacbti. [Was RE: [Patch 1/7, Arm, GCC] Add Armv8.1-M Mainline target feature +pacbti.]

On 28/10/2021 12:41, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Richard Earnshaw Sent: Monday, October 11, 2021 1:29 PM To: Tejas Belagod ; gcc-patches@gcc.gnu.org Subject: Re: [Patch 1/7, Arm, GCC] Add Armv8.1-M Mainline target feature +pacbti. On 08/10/2021 13

Re: [Patch 3/8, Arm, GCC] Add option -mbranch-protection. [Was RE: [Patch 2/7, Arm, GCC] Add option -mbranch-protection.]

On 28/10/2021 12:42, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Richard Earnshaw Sent: Monday, October 11, 2021 1:58 PM To: Tejas Belagod ; gcc-patches@gcc.gnu.org Subject: Re: [Patch 2/7, Arm, GCC] Add option -mbranch-protection. On 08/10/2021 13:17, Tejas Bela

  1   2   3   4   >