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

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 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 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

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):

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

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 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 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: *

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

Co-Authored-By: Richard Earnshaw +@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 (armv8.1-m.main only). +@samp{none} generate code without branch

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 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

[committed] arm: more testsutie fallout for mve move-immediate changes

Unfortunately, there is more fall-out in the testsuite for my changes to use MVE move-immediate operations instead of literal pool loads. Fixed as follows: gcc/testsuite/ChangeLog: * gcc.target/arm/simd/mve-vcmp-f32-2.c: Adjust expected output. * gcc.target/arm/simd/pr100757.c:

[committed] arm: fix checking ICE in arm_print_operand [PR106004]

Sigh, another instance where I incorrectly used XUINT instead of UINTVAL. I've also made the code here a little more robust (although I think this case can't in fact be reached) if the 32-bit clear mask includes bit 31. This case, if reached, would print out an out-of-range value based on the

[committed] arm: mve: Don't force trivial vector literals to the pool

A bug in the ordering of the operands in the mve_mov pattern meant that all literal values were being pushed to the literal pool. This patch fixes that and simplifies some of the logic slightly so that we can use as simple switch statement. For example: void f (uint32_t *a) { int i; for (i =

[committed] arm: big-endian issue in gen_cpymem_ldrd_strd [PR105981]

The code in gen_cpymem_ldrd_strd has been incorrect for big-endian since r230663. The problem is that we use gen_lowpart, etc. to split the 64-bit quantity, but fail to account for the fact that these routines are really dealing with 64-bit /values/ and in big-endian the ordering of the

[committed] arm: fix thinko in arm_bfi_1_p() [PR105974]

I clearly wasn't thinking straight when I wrote the arm_bfi_1_p function and used XUINT rather than UINTVAL when extracting CONST_INT values. It seemed to work in testing, but was incorrect and failed RTL checking. Fixed thusly: gcc/ChangeLog: PR target/105974 *

[committed] arm: Improve code generation for BFI and BFC [PR105090]

This patch, in response to PR105090, makes some general improvements to the code generation when BFI and BFC instructions are available. Firstly we handle more cases where the RTL does not generate an INSV operation due to a lack of a tie between the input and output, but we nevertheless need to

[committed 2/2] arm: correctly handle misaligned MEMs on MVE [PR105463]

Vector operations in MVE must be aligned to the element size, so if we are asked for a misaligned move in a wider mode we must recast it to a form suitable for the known alignment (larger elements have better address offset ranges, so there is some advantage to using wider element sizes if

[committed 1/2] arm: fix some issues in mve_vector_mem_operand

There are a couple of issues with the mve_vector_mem_operand function. Firstly, SP is permitted as a register provided there is no write-back operation. Secondly, there were some cases where 'strict' was not being applied when checking which registers had been used. gcc/ChangeLog: *

Re: [PATCH] gimple-isel: handle x CMP y ? z : 0

On 04/05/2022 12:14, Richard Biener wrote: On Wed, May 4, 2022 at 12:16 PM Richard Earnshaw via Gcc-patches wrote: Gimple isel already handles x CMP y ? -1 : 0 when lowering vector cond operations, but this can be generalized further when the comparison forms a natural mask so that we can

[PATCH] gimple-isel: handle x CMP y ? z : 0

Gimple isel already handles x CMP y ? -1 : 0 when lowering vector cond operations, but this can be generalized further when the comparison forms a natural mask so that we can also handle x CMP y ? z : 0 by transforming it into (x CMP y) & z. This will, in most cases save having to load a

[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

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

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] 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] 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: [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

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?

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

[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

[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

[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

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

[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

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.

[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: *

[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 *

[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. ---

[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

[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: *

[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

[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.

[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: *

[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

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

it is not needed. The final patch adds a testcase. Richard Earnshaw (7): arm: Disambiguate multiple crypto patterns with the same name. arm: Consistently use crypto_mode attribute in crypto patterns arm: Add option for mitigating against Cortex-A CPU erratum for AES arm: add basic mitigation

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

Re: [PATCH] Fix -Wformat-diag for ARM target.

On 12/01/2022 12:59, Martin Liška wrote: Hello. We've got -Wformat-diag for some time and I think we should start using it in -Werror for GCC bootstrap. The following patch removes last pieces of the warning for ARM target. > diff --git a/gcc/config/arm/arm-builtins.c

Re: [PATCH] Fix -Wformat-diag for aarch64 target.

On 12/01/2022 09:02, Martin Liška wrote: Hello. We've got -Wformat-diag for some time and I think we should start using it in -Werror for GCC bootstrap. The following patch removes last pieces of the warning for aarch64 target. Ready to be installed? Thanks, Martin OK. R.

Re: [PATCH][GCC] arm: fix __arm_vld1q_z* and __arm_vst1q_p* intrinsics.

On 22/12/2021 15:55, Murray Steele via Gcc-patches wrote: > Hi All, > > This patch fixes the implementation of the existing __arm_vld1q_z* and > __arm_vst1q_p* MVE intrinsic functions. > > The MVE ACLE allows for __ARM_MVE_PRESERVE_USER_NAMESPACE to be defined, > which removes definitions for

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

On 09/12/2021 15:24, Murray Steele via Gcc-patches wrote: Changes from original patch: 1. Make mentioned changes to changelog. 2. Add namespace-end comments. 3. Add #error for when arm-mve-builtins.def is included without defining DEF_MVE_TYPE. 4. Make placement of '#undef DEF_MVE_TYPE'

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

On 24/11/2021 12:18, Richard Earnshaw via Gcc-patches wrote: 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

Re: [PATCH] [1/2] arm: Implement cortex-M return signing address codegen

On 17/12/2021 15:52, Andrea Corallo wrote: Hi Richard, thanks for reviewing! Some comments inline. Richard Earnshaw writes: On 05/11/2021 08:52, Andrea Corallo via Gcc-patches wrote: Hi all, this patch enables address return signature and verification based on Armv8.1-M Pointer

Re: [Patch 7/8 V2] Arm: Emit build attributes for PACBTI target feature.

On 10/12/2021 16:36, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw via Gcc-patches writes: On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Gcc-patches On Behalf Of Tejas Belagod via Gcc-patches Sent: Friday, October 8, 2021 1:19 PM

Re: [Patch 7/8 V2] Arm: Emit build attributes for PACBTI target feature.

On 10/12/2021 16:36, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw via Gcc-patches writes: On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Gcc-patches On Behalf Of Tejas Belagod via Gcc-patches Sent: Friday, October 8, 2021 1:19 PM

Re: [Patch 6/8 V2] Arm: Add pointer authentication for stack-unwinding runtime.

On 09/12/2021 17:36, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw via Gcc-patches writes: On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Gcc-patches On Behalf Of Tejas Belagod via Gcc-patches Sent: Friday, October 8, 2021 1:18 PM

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

On 08/12/2021 15:39, Murray Steele via Gcc-patches wrote: > Hi, > > Thank you for the feedback, I'll make the noted changes to the changelog and > add the missing end-of-namespace comments. > > On 08/12/2021 15:23, Richard Earnshaw wrote: > >> diff --git a/gcc/conf

Re: [patch, Fortran] IEEE support for aarch64-apple-darwin

On 08/12/2021 15:47, FX via Gcc-patches wrote: Hi Richard, This isn't a full review, but I do have a question: is this really specific to Darwin? or is it really generic aarch64 code? If the former, then the file name is not right and it should reflect the darwin-specific nature of the

Re: [patch, Fortran] IEEE support for aarch64-apple-darwin

On 06/12/2021 16:32, FX via Gcc-patches wrote: Hi everyone, Since support for target aarch64-apple-darwin has been submitted for review, it’s time to submit the Fortran part, i.e. enabling IEEE support on that target. The patch has been in use now for several months, in a developer branch

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

On 25/11/2021 09:42, Murray Steele via Gcc-patches wrote: Changes from original patch: 1. Merged test_redef_* test files into one 2. Encapsulated contents of arm-mve-builtins.h in namespace arm_mve (missed in initial patch). 3. Added extern declarations for scalar_types and acle_vector

Re: [PATCH] [2/2] arm: add arm bti pass

On 05/11/2021 08:55, Andrea Corallo via Gcc-patches wrote: Hi all, this patch enables Branch Target Identification Armv8.1-M Mechanism [1]. This is achieved by moving and generalizing the Aarch64 "bti" pass so it can be used also by the Arm backend. The pass iterates through the

Re: [PATCH] [1/2] arm: Implement cortex-M return signing address codegen

On 05/11/2021 08:52, Andrea Corallo via Gcc-patches wrote: Hi all, this patch enables 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 signing LR using SP

Re: [Patch 8/8, Arm, GCC] Introduce multilibs for PACBTI target feature. [Was RE: [Patch 7/7, Arm, GCC] Introduce multilibs for PACBTI target feature.]

On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Gcc-patches On Behalf Of Tejas Belagod via Gcc-patches Sent: Friday, October 8, 2021 1:19 PM To: gcc-patches@gcc.gnu.org Subject: [Patch 7/7, Arm, GCC] Introduce multilibs for PACBTI target feature.

Re: [Patch 7/8, Arm, GCC] Emit build attributes for PACBTI target feature. [ Was RE: [Patch 6/7, Arm, GCC] Emit build attributes for PACBTI target feature.]

On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Gcc-patches On Behalf Of Tejas Belagod via Gcc-patches Sent: Friday, October 8, 2021 1:19 PM To: gcc-patches@gcc.gnu.org Subject: [Patch 6/7, Arm, GCC] Emit build attributes for PACBTI target

Re: [Patch 6/8, Arm. GCC] Add pointer authentication for stack-unwinding runtime. [Was RE: [Patch 5/7, Arm. GCC] Add pointer authentication for stack-unwinding runtime.]

On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Gcc-patches On Behalf Of Tejas Belagod via Gcc-patches Sent: Friday, October 8, 2021 1:18 PM To: gcc-patches@gcc.gnu.org Subject: [Patch 5/7, Arm. GCC] Add pointer authentication for stack-

Re: [Patch 5/8, Arm, GCC] Implement target feature macros for PACBTI. [Was RE: [Patch 4/7, Arm. GCC] Implement target feature macros for PACBTI.]

On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Richard Earnshaw Sent: Monday, October 11, 2021 2:58 PM To: Tejas Belagod ; gcc-patches@gcc.gnu.org Subject: Re: [Patch 4/7, Arm. GCC] Implement target feature macros for PACBTI. On 08/10/2021 13

Re: [Patch 4/8, Arm. GCC] Add testsuite library support for PACBTI target. [Was RE: [Patch 3/7, Arm, GCC] Add testsuite library support for PACBTI target.]

On 28/10/2021 12:42, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Richard Earnshaw Sent: Monday, October 11, 2021 2:38 PM To: Tejas Belagod ; gcc-patches@gcc.gnu.org Subject: Re: [Patch 3/7, Arm, GCC] Add testsuite library support for PACBTI target. On 11/10/2021

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

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

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 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

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

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

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

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,

Re: [PATCH][GCC] arm: add armv9-a architecture to -march

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 ; Ramana Radhakrishnan ; Kyrylo Tkachov ; ni...@redhat.com Subject: [PATCH][GCC] arm: add armv9-a architecture to -march Hi, This patch is

Re: [PATCH] Darwin, Arm64 : Initial support for the self-host driver.

On 05/11/2021 15:14, Iain Sandoe via Gcc-patches wrote: This allows people to host a c-family/fortran GCC cross-compiler on aarch64-apple-darwin (support for Ada will follow in a separate patch). At present, there is no special action needed for aarch64-darwin; this just pulls in generic

Re: [PATCH]middle-end convert negate + right shift into compare greater.

On 15/10/2021 10:06, Richard Biener via Gcc-patches wrote: On Fri, 15 Oct 2021, Tamar Christina wrote: +/* Fold (-x >> C) into x > 0 where C = precision(type) - 1. */ (for +cst (INTEGER_CST VECTOR_CST) (simplify + (rshift (negate:s @0) cst@1) + (if (!flag_wrapv) Don't test flag_wrapv

Re: [Patch 4/7, Arm. GCC] Implement target feature macros for PACBTI.

On 08/10/2021 13:18, Tejas Belagod via Gcc-patches wrote: Hi, This patch implements target feature macros when PACBTI is enabled through the -march option or -mbranch-protection. Tested on arm-none-eabi. OK for trunk? 2021-10-04 Tejas Belagod gcc/ChangeLog: * config/arm/arm-c.c

Re: [Patch 3/7, Arm, GCC] Add testsuite library support for PACBTI target.

On 11/10/2021 14:36, Richard Earnshaw via Gcc-patches wrote: On 08/10/2021 13:17, Tejas Belagod via Gcc-patches wrote: Hi, Add targeting-checking entities for PACBTI in testsuite framework. Tested on arm-none-eabi. OK for trunk? 2021-10-04  Tejas Belagod  gcc/ChangeLog: * testsuite

Re: [Patch 3/7, Arm, GCC] Add testsuite library support for PACBTI target.

On 08/10/2021 13:17, Tejas Belagod via Gcc-patches wrote: Hi, Add targeting-checking entities for PACBTI in testsuite framework. Tested on arm-none-eabi. OK for trunk? 2021-10-04 Tejas Belagod gcc/ChangeLog: * testsuite/lib/target-supports.exp

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

On 08/10/2021 13:17, Tejas Belagod via Gcc-patches wrote: Hi, Add -mbranch-protection option and its associated parsing routines. This option enables the code-generation of pointer signing and authentication instructions in function prologues and epilogues. Tested on arm-none-eabi. OK for

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

On 08/10/2021 13:17, Tejas Belagod via Gcc-patches wrote: Hi, This patch adds the -march feature +pacbti to Armv8.1-M Mainline. This feature enables pointer signing and authentication instructions on M-class architectures. Tested on arm-none-eabi. OK for trunk? 2021-10-04 Tejas Belagod

Re: [PATCH]middle-end convert negate + right shift into compare greater.

On 05/10/2021 14:56, Tamar Christina via Gcc-patches wrote: -Original Message- From: Richard Earnshaw Sent: Tuesday, October 5, 2021 2:52 PM To: Tamar Christina ; gcc-patches@gcc.gnu.org Cc: nd ; rguent...@suse.de Subject: Re: [PATCH]middle-end convert negate + right shift

Re: [PATCH]middle-end convert negate + right shift into compare greater.

On 05/10/2021 14:49, Tamar Christina wrote: -Original Message- From: Richard Earnshaw Sent: Tuesday, October 5, 2021 2:34 PM To: Tamar Christina ; gcc-patches@gcc.gnu.org Cc: nd ; rguent...@suse.de Subject: Re: [PATCH]middle-end convert negate + right shift into compare greater

Re: [PATCH]middle-end convert negate + right shift into compare greater.

On 05/10/2021 14:30, Tamar Christina wrote: -Original Message- From: Richard Earnshaw Sent: Tuesday, October 5, 2021 1:56 PM To: Tamar Christina ; gcc-patches@gcc.gnu.org Cc: nd ; rguent...@suse.de Subject: Re: [PATCH]middle-end convert negate + right shift into compare greater

Re: [PATCH]middle-end convert negate + right shift into compare greater.

On 05/10/2021 13:50, Tamar Christina via Gcc-patches wrote: Hi All, This turns an inversion of the sign bit + arithmetic right shift into a comparison with 0. i.e. void fun1(int32_t *x, int n) { for (int i = 0; i < (n & -16); i++) x[i] = (-x[i]) >> 31; } Notwithstanding that I

Re: [PATCH][GCC] arm: Add Cortex-R52+ multilib

I think the RTEMS multilibs are based on the products that RTEMS supports, so this is really the RTEMS maintainers' call. Joel? On 22/09/2021 09:46, Przemyslaw Wirkus via Gcc-patches wrote: Patch is adding multilib entries for `cortex-r52plus` CPU. See:

[committed] arm: pass architecture extensions to assembler if supported

When I originally added the new extended architecture features support to GCC, the assembler was unable to parse the new feature lists on the command-line and would throw an error. This has now been fixed in GAS and the behaviour is the same as GCC. So this patch adds a configure-time test for

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

On 20/09/2021 16:51, Qing Zhao via Gcc-patches wrote: On Sep 20, 2021, at 9:36 AM, Richard Earnshaw wrote: On 20/09/2021 14:55, Qing Zhao wrote: On Sep 20, 2021, at 8:18 AM, Richard Earnshaw wrote: On 20/09/2021 13:47, Qing Zhao wrote: On Sep 20, 2021, at 5:43 AM, Richard

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

On 20/09/2021 14:55, Qing Zhao wrote: On Sep 20, 2021, at 8:18 AM, Richard Earnshaw wrote: On 20/09/2021 13:47, Qing Zhao wrote: On Sep 20, 2021, at 5:43 AM, Richard Earnshaw wrote: On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote: Hi, There are much less issues

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

On 20/09/2021 13:47, Qing Zhao wrote: On Sep 20, 2021, at 5:43 AM, Richard Earnshaw wrote: On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote: Hi, There are much less issues with aarch64/auto-init-* test cases. Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote: Hi, There are much less issues with aarch64/auto-init-* test cases. Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, ‘armv8-r’) do not change the pattern match. Only 1. -mabi=ilp32/lp64 impact two of the testing

Re: [PATCH] testsuite: Make sure double-precision is supported in g++.dg/eh/arm-vfp-unwind.C

On 16/09/2021 10:12, Christophe LYON via Gcc-patches wrote: On 15/09/2021 18:43, Richard Earnshaw via Gcc-patches wrote: On 15/09/2021 17:13, Christophe Lyon via Gcc-patches wrote: On Wed, Sep 15, 2021 at 2:49 PM Richard Earnshaw via Gcc-patches < gcc-patches@gcc.gnu.org>

Re: [PATCH] testsuite: Make sure double-precision is supported in g++.dg/eh/arm-vfp-unwind.C

On 15/09/2021 17:13, Christophe Lyon via Gcc-patches wrote: On Wed, Sep 15, 2021 at 2:49 PM Richard Earnshaw via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: On 15/09/2021 13:26, Christophe LYON via Gcc-patches wrote: On 15/09/2021 13:02, Richard Earnshaw wrote: On 26/08/2021

Re: [PATCH] testsuite: Make sure double-precision is supported in g++.dg/eh/arm-vfp-unwind.C

On 15/09/2021 13:26, Christophe LYON via Gcc-patches wrote: On 15/09/2021 13:02, Richard Earnshaw wrote: On 26/08/2021 16:53, Christophe Lyon via Gcc-patches wrote: g++.dg/eh/arm-vfp-unwind.C uses an asm statement relying on double-precision FPU support, but does not make sure

Re: [PATCH] testsuite: Make sure double-precision is supported in g++.dg/eh/arm-vfp-unwind.C

On 26/08/2021 16:53, Christophe Lyon via Gcc-patches wrote: g++.dg/eh/arm-vfp-unwind.C uses an asm statement relying on double-precision FPU support, but does not make sure it is actually supported by the target. Check (__ARM_FP & 8) to ensure this. 2021-08-26 Christophe Lyon

Re: [PATCH RFC] c++: implement C++17 hardware interference size

On 14/09/2021 08:56, Christophe LYON via Gcc-patches wrote: On 10/09/2021 15:16, Jason Merrill via Gcc-patches wrote: OK, time to finish this up.  The main change relative to the last patch I sent to the list is dropping the -finterference-tune flag and making that behavior the default. 

Re: [PATCH v3 1/3] rtl: directly handle MEM in gen_highpart [PR102125]

On 13/09/2021 10:38, Richard Sandiford via Gcc-patches wrote: Richard Earnshaw via Gcc-patches writes: gen_lowpart_general handles forming a lowpart of a MEM by using adjust_address to rework and validate a new version of the MEM. Do the same for gen_highpart rather than calling

[PATCH v3 3/3] gimple: allow more folding of memcpy [PR102125]

The current restriction on folding memcpy to a single element of size MOVE_MAX is excessively cautious on most machines and limits some significant further optimizations. So relax the restriction provided the copy size does not exceed MOVE_MAX * MOVE_RATIO and that a SET insn exists for moving

<    1   2   3   4   5   6   7   8   9   10   >