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

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/lib/target

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

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

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 feature

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

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 ty

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 s

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 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/config/arm/arm-mve-builtins.def >>

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 To

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 To

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 To

Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM

On 14/10/2022 09:34, Haochen Jiang via Gcc-patches wrote: gcc/ChangeLog: * builtins.cc (expand_builtin_prefetch): Handle the fourth parameter in expand function. * config/aarch64/aarch64-sve.md: Add default parameter value. * config/aarch64/aarch64.md (prefetch

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

On 20/10/2022 15:47, Kyrylo Tkachov via Gcc-patches wrote: Hi Andrea, -Original Message- From: Gcc-patches On Behalf Of Andrea Corallo via Gcc-patches Sent: Friday, August 12, 2022 4:31 PM To: Andrea Corallo via Gcc-patches Cc: Richard Earnshaw ; nd Subject: [PATCH 7/15] arm: Emit

Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM

On 20/10/2022 18:37, Andrew Pinski via Gcc-patches wrote: On Thu, Oct 20, 2022 at 10:28 AM Segher Boessenkool wrote: On Thu, Oct 20, 2022 at 01:44:15AM +, Jiang, Haochen wrote: Maybe the testcase change cause some misunderstanding and concern. Actually, the patch did not disrupt the p

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

On 12/08/2022 16:30, 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 9/15] arm: Set again stack pointer as CFA reg when popping if necessary

On 27/09/2022 16:24, Kyrylo Tkachov via Gcc-patches wrote: -Original Message- From: Andrea Corallo Sent: Tuesday, September 27, 2022 11:06 AM To: Kyrylo Tkachov Cc: Andrea Corallo via Gcc-patches ; Richard Earnshaw ; nd Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CF

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

On 14/09/2022 15:20, 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 13/15] arm: Add pacbti related multilib support for armv8.1-m.main.

On 12/08/2022 18:10, Srinath Parvathaneni via Gcc-patches wrote: Hi, This patch supports following -march/-mbranch-protection combination by linking them to existing pacbti multilibs. $ -march=armv8.1-m.main+pacbti+fp.dp+mve.fp -mbranch-protection=standard -mfloat-abi=hard -mthumb $ -mar

Re: [PING][PATCH 0/15] arm: Enables return address verification and branch target identification on Cortex-M

On 21/09/2022 09:07, Andrea Corallo via Gcc-patches wrote: Hi all, ping^2 for patches 9/15 7/15 11/15 12/15 and 10/15 V2 of this series. Andrea Subject says xx/15, but I only see 1-12 from you. R.

Re: [PATCH] arm: Define with_float to hard when target name ends with hf

On 17/08/2022 09:35, Christophe Lyon via Gcc-patches wrote: On arm, the --with-float= configure option is used to define include files search path (among other things). However, when targeting arm-linux-gnueabihf, one would expect to automatically default to the hard-float ABI, but this is no

Re: [PATCH, GCC, AARCH64, 5/6] Enable BTI : Add new pass for BTI.

On 18/08/2022 01:00, Andrew Pinski via Gcc-patches wrote: On Fri, Nov 2, 2018 at 11:39 AM Sudakshina Das wrote: Hi This patch is part of a series that enables ARMv8.5-A in GCC and adds Branch Target Identification Mechanism. (https://developer.arm.com/products/architecture/cpu-architecture

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

On 12/08/2022 18: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: [GCC 13/15][PATCH v3] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

On 19/08/2022 11:04, Srinath Parvathaneni via Gcc-patches wrote: Hello, This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo hard-register and also .save {ra_auth_code} and .cfi_offset ra_auth_code dwarf directives for the PAC feature in Armv8.1-M architecture. RA_AUTH_CO

Re: [PATCH][committed] aarch64: Suggest an -mcpu option when user passes CPU name to -march

On 05/09/2022 14:35, Kyrylo Tkachov via Gcc-patches wrote: Hi all, This small patch helps users who confuse -march and -mcpu on AArch64. Sometimes users pass -march with a CPU name, where they most likely wanted to use -mcpu, which would select the right architecture features *and* tune for t

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

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

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

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

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

On 02/11/2020 10:24, Christophe Lyon via Gcc-patches wrote: > Hi, > > On Fri, 30 Oct 2020 at 13:49, Richard Earnshaw > wrote: >> >> On 29/10/2020 19:18, Richard Earnshaw via Gcc-patches wrote: >>> On 28/10/2020 18:10, Christophe Lyon via Gcc-patches wrote:

[PATCH 1/3] rtl: allow forming subregs of already unaligned mems [PR102125]

GCC was recently changed to prevent simplify_subreg from simplifying a subreg of a mem when the mode of the new mem would have stricter alignment constraints than the inner mem already has when the target requires STRICT_ALIGNMENT. However, such targets may have specialist patterns that can handl

[PATCH 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 th

[PATCH 0/3] lower more cases of memcpy [PR102125]

This short patch series is designed to address some more cases where we can usefully lower memcpy operations during gimple fold. The current code restricts this lowering to a maximum size of MOVE_MAX, ie the size of a single integer register on the machine, but with modern architectures this is li

[PATCH 2/3] arm: expand handling of movmisalign for DImode [PR102125]

DImode is currently handled only for machines with vector modes enabled, but this is unduly restrictive and is generally better done in core registers. gcc/ChangeLog: PR target/102125 * config/arm/arm.md (movmisaligndi): New define_expand. * config/arm/vec-common.md (movm

Re: [PATCH 1/3] rtl: allow forming subregs of already unaligned mems [PR102125]

On 06/09/2021 11:58, Richard Biener via Gcc-patches wrote: On Mon, Sep 6, 2021 at 12:40 PM Richard Earnshaw wrote: GCC was recently changed to prevent simplify_subreg from simplifying a subreg of a mem when the mode of the new mem would have stricter alignment constraints than the inner me

Re: [PATCH 1/3] rtl: allow forming subregs of already unaligned mems [PR102125]

On 06/09/2021 12:13, Richard Biener wrote: On Mon, Sep 6, 2021 at 1:08 PM Richard Earnshaw wrote: On 06/09/2021 11:58, Richard Biener via Gcc-patches wrote: On Mon, Sep 6, 2021 at 12:40 PM Richard Earnshaw wrote: GCC was recently changed to prevent simplify_subreg from simplifying a

Re: [PATCH 04/13] arm: Add GENERAL_AND_VPR_REGS regclass

On 07/09/2021 10:15, Christophe Lyon via Gcc-patches wrote: At some point during the development of this patch series, it appeared that in some cases the register allocator wants “VPR or general” rather than “VPR or general or FP” (which is the same thing as ALL_REGS). The series does not see

Re: [PATCH 04/13] arm: Add GENERAL_AND_VPR_REGS regclass

On 07/09/2021 13:05, Christophe LYON wrote: On 07/09/2021 11:42, Richard Earnshaw wrote: On 07/09/2021 10:15, Christophe Lyon via Gcc-patches wrote: At some point during the development of this patch series, it appeared that in some cases the register allocator wants “VPR or general” rath

[PATCH v2 0/3] lower more cases of memcpy [PR102125]

Changes since version 1: patch 1 is reworked entirely to handle SUBREG (MEM) in gen_highpart. This brings it more in line with the way gen_lowpart_general handles this case. patch 2 is simplified because, having reread the manual description of movmisalign I realised that this pattern can never

[PATCH v2 1/3] rtl: properly handle subreg (mem) in gen_highpart [PR102125]

gen_lowpart_general handles forming a SUBREG of a MEM by using adjust_address to rework and validate a new version of the MEM. However, gen_highpart does not attempt this and simply returns (SUBREG (MEM)) if the change is not 'obviously' safe. Improve on that by using a similar approach so that g

[PATCH v2 2/3] arm: expand handling of movmisalign for DImode [PR102125]

DImode is currently handled only for machines with vector modes enabled, but this is unduly restrictive and is generally better done in core registers. gcc/ChangeLog: PR target/102125 * config/arm/arm.md (movmisaligndi): New define_expand. * config/arm/vec-common.md (movm

[PATCH v2 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 th

Re: [PATCH v2 1/3] rtl: properly handle subreg (mem) in gen_highpart [PR102125]

On 09/09/2021 13:23, Richard Biener via Gcc-patches wrote: On Thu, Sep 9, 2021 at 1:09 PM Richard Earnshaw wrote: gen_lowpart_general handles forming a SUBREG of a MEM by using adjust_address to rework and validate a new version of the MEM. However, gen_highpart does not attempt this and s

[PATCH v3 0/3] lower more cases of memcpy [PR102125]

Changes since version 2: patch 1 is reworked again. patch 2 is unchanged from v2, it's included here only for completeness. patch 3 is unchanged, it's included here only for completeness. - This short patch series is designed to address some more cases where we can usefully lower

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

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 simplify_gen_subreg for this case. gcc/ChangeLog: PR target/102125 * emit-rtl.c (gen_highpart): Use adj

[PATCH v3 2/3] arm: expand handling of movmisalign for DImode [PR102125]

DImode is currently handled only for machines with vector modes enabled, but this is unduly restrictive and is generally better done in core registers. gcc/ChangeLog: PR target/102125 * config/arm/arm.md (movmisaligndi): New define_expand. * config/arm/vec-common.md (movm

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

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

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

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

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 it is actua

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

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 c

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-a’,

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

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 Earnsh

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

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: https://www.arm.com/products/silicon-ip

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 Darw

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 ju

Re: [PATCH] arm/testsuite: Fix testcase for PR99977

On 19/05/2021 09:10, Christophe Lyon via Gcc-patches wrote: Some targets (eg arm-none-uclinuxfdpiceabi) do not support Thumb-1, and since the testcase forces -march=armv8-m.base, we need to check whether this option is actually supported. Using dg-add-options arm_arch_v8m_base ensure that we

Re: [GCC-10 backport][PATCH] arm: _Generic feature failing with ICE for -O0 (pr97205).

Looking through the bugzilla logs shows: Since it is a gcc_checking_assert that triggers the ICE, I assumed that does not affect a release build, is that correct? So it would appear that the decision was taken that a backport was not needed. Have I missed something? R. On 19/05/2021 1

Re: [PATCH] arm: Fix ICE with CMSE nonsecure call on Armv8.1-M [PR100333]

ENOATTACHMENT. On 19/05/2021 15:42, Alex Coplan via Gcc-patches wrote: Hi Richard, On 17/05/2021 17:31, Richard Earnshaw wrote: On 30/04/2021 09:30, Alex Coplan via Gcc-patches wrote: Hi, As the PR shows, we ICE shortly after expanding nonsecure calls for Armv8.1-M. For Armv8.1-M, we have

Re: [PATCH] arm: Fix ICE with CMSE nonsecure call on Armv8.1-M [PR100333]

On 19/05/2021 15:44, Alex Coplan via Gcc-patches wrote: This time with attachment. On 19/05/2021 15:42, Alex Coplan via Gcc-patches wrote: Hi Richard, On 17/05/2021 17:31, Richard Earnshaw wrote: On 30/04/2021 09:30, Alex Coplan via Gcc-patches wrote: Hi, As the PR shows, we ICE shortl

[committed] arm: Remove use of opts_set in arm_configure_build_target [PR100767]

The variable global_options_set is a reflection of which options have been explicitly set from the command line in the structure global_options. But it doesn't describe the contents of a cl_target_option. cl_target_option is a set of options to apply and once configured should represent a viable

Re: [PATCH] ARM: reset arm_fp16_format

On 01/06/2021 15:05, Martin Liška wrote: Hello. The patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98636#c20 where target option restore can be called and arm_fp16_format should be reset to ARM_FP16_FORMAT_NONE. It fixes the ICE in the PR. Can please ARM folks test me the patch

Re: [GCC][PATCH] arm: Fix multilib mapping for CDE extensions.

On 01/06/2021 18:08, Srinath Parvathaneni via Gcc-patches wrote: Hi All, On passing +cdecp[0-7] extension to the -march string in command line options, multilib linking is failing as mentioned in PR100856. This patch fixes this issue by generating a separate -march string only for multilib co

Re: [GCC][Patch] arm: Fix the mve multilib for the broken cmse support (pr99939).

On 01/06/2021 18:16, Srinath Parvathaneni via Gcc-patches wrote: Hi Richard, -Original Message- From: Richard Earnshaw Sent: 13 April 2021 14:55 To: Srinath Parvathaneni ; gcc- patc...@gcc.gnu.org Cc: Richard Earnshaw Subject: Re: [GCC][Patch] arm: Fix the mve multilib for the brok

Re: [PATCH] AArch64: Improve address rematerialization costs

On 02/06/2021 11:21, Wilco Dijkstra via Gcc-patches wrote: Hi, Given the large improvements from better register allocation of GOT accesses, I decided to generalize it to get large gains for normal addressing too: Improve rematerialization costs of addresses. The current costs are set too

Re: [GCC][Patch] arm: Fix the mve multilib for the broken cmse support (pr99939).

On 11/06/2021 14:02, Srinath Parvathaneni via Gcc-patches wrote: Hi Richard, I have addressed all your review comments in https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571739.html in the following patch. The current CMSE support in the multilib build for "-march=armv8.1-m.main+mve -m

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]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 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. On

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

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 gcc

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 trunk

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

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

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 di

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

On 16/07/2021 12:17, Jonathan Wakely via Gcc-patches wrote: On Fri, 16 Jul 2021 at 03:51, Noah Goldstein wrote: On intel x86 systems with a private L2 cache the spatial prefetcher can cause destructive interference along 128 byte aligned boundaries. https://www.intel.com/content/dam/www/publi

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

On 17/07/2021 22:37, Jason Merrill via Gcc-patches wrote: On Sat, Jul 17, 2021 at 6:55 AM Matthias Kretz wrote: On Saturday, 17 July 2021 15:32:42 CEST Jonathan Wakely wrote: On Sat, 17 Jul 2021, 09:15 Matthias Kretz, wrote: If somebody writes a library with `keep_apart` in the public AP

Re: [committed] .dir-locals.el: Set 'fill-column' to 80 for c-mode

On 14/12/2020 11:29, Andrea Corallo via Gcc-patches wrote: Hi all, I've committed the attached patch as obvious. This is to set `fill-column' to 80 in c-mode (Emacs default it to 70) so now M-q does the right thing. I think is very handy especially in comments. Question: should we update t

Re: [PATCH] gcc_update: use gcc-descr git alias for revision string in gcc/REVISION

On 16/07/2021 08:29, Jakub Jelinek via Gcc-patches wrote: > On Fri, Jul 16, 2021 at 09:06:01AM +0200, Richard Biener via Gcc-patches > wrote: >> On Thu, Jul 15, 2021 at 9:12 PM Serge Belyshev >> wrote: >>> >>> This is to make development version string more readable, and >>> to simplify navigatio

Re: [committed] .dir-locals.el: Set 'fill-column' to 80 for c-mode

On 19/07/2021 14:52, Richard Sandiford via Gcc-patches wrote: Richard Earnshaw via Gcc-patches writes: On 14/12/2020 11:29, Andrea Corallo via Gcc-patches wrote: Hi all, I've committed the attached patch as obvious. This is to set `fill-column' to 80 in c-mode (Emacs default it

[committed] dir-locals: Use https for bug references

We've been using https for web references for some time now. ChangeLog: * .dir-locals.el (bug-reference-url-format): Use https. --- .dir-locals.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.dir-locals.el b/.dir-locals.el index b07a0dc50d8..fa031cbded9 100644 --

Re: [ARM] PR66791: Replace builtins in vshl_n

On 22/07/2021 08:45, Prathamesh Kulkarni via Gcc-patches wrote: Hi, The attached patch removes calls to builtins from vshl_n intrinsics, and replacing them with left shift operator. The patch passes bootstrap+test on arm-linux-gnueabihf. Altho, I noticed, that the patch causes 3 extra registe

Re: [ARM] PR66791: Replace builtins in vshl_n

On 22/07/2021 12:32, Prathamesh Kulkarni wrote: On Thu, 22 Jul 2021 at 16:03, Richard Earnshaw wrote: On 22/07/2021 08:45, Prathamesh Kulkarni via Gcc-patches wrote: Hi, The attached patch removes calls to builtins from vshl_n intrinsics, and replacing them with left shift operator. The

Re: [ARM] PR66791: Replace builtins in vshl_n

On 22/07/2021 14:47, Prathamesh Kulkarni via Gcc-patches wrote: On Thu, 22 Jul 2021 at 17:28, Richard Earnshaw wrote: On 22/07/2021 12:32, Prathamesh Kulkarni wrote: On Thu, 22 Jul 2021 at 16:03, Richard Earnshaw wrote: On 22/07/2021 08:45, Prathamesh Kulkarni via Gcc-patches wrote:

Re: [ARM] PR66791: Replace builtins in vshl_n

On 23/07/2021 08:04, Prathamesh Kulkarni via Gcc-patches wrote: > On Thu, 22 Jul 2021 at 20:29, Richard Earnshaw > wrote: >> >> >> >> On 22/07/2021 14:47, Prathamesh Kulkarni via Gcc-patches wrote: >>> On Thu, 22 Jul 2021 at 17:28, Richard Earnshaw >>> wrote: On 22/07/2021 12:

[committed] arm: fix UB when compiling thumb2 with PIC [PR100236]

arm_compute_save_core_reg_mask contains UB in that the saved PIC register number is used to create a bit mask. However, for some target options this register is undefined and we end up with a shift of ~0. On native compilations this is benign since the shift will still be large enough to move the

Re: [PATCH] aarch64: Fix UB in the compiler [PR100200]

On 27/04/2021 14:16, Jakub Jelinek via Gcc-patches wrote: Hi! The following patch fixes UBs in the compiler when negativing a CONST_INT containing HOST_WIDE_INT_MIN. I've changed the spots where there wasn't an obvious earlier condition check or predicate that would fail for such CONST_INTs.

sel-sched: fix UB in init_regs_for_mode [PR100311]

init_regs_for_mode iterates over all hard regs for the machine to test if the reg is OK for the mode, but an arithmetic overflow can lead to testing elements beyond the end of the arrays allocated for fixed and global registers. Clearly, if a mode requiring multiple hard regs needs one beyond

Re: sel-sched: fix UB in init_regs_for_mode [PR100311]

On 28/04/2021 12:22, Jakub Jelinek via Gcc-patches wrote: On Wed, Apr 28, 2021 at 12:04:45PM +0100, Richard Earnshaw wrote: init_regs_for_mode iterates over all hard regs for the machine to test if the reg is OK for the mode, but an arithmetic overflow can lead to testing elements beyond the

[committed] arm: fix UB due to missing mode check [PR100311]

Some places in the compiler iterate over all the fixed registers to check if that register can be used in a particular mode. The idiom is to iterate over the register and then for that register, if it supports the current mode to check all that register and any additional registers needed (HARD_R

Re: [PATCH] Remove CC0

On 04/05/2021 17:22, Eric Botcazou wrote: A quick look through the code suggests it's being used for thumb1 code gen to try to reproduce the traditional CC0 type behaviour of eliminating redundant compare operations when you have sequences such as cmp a, b b d1 cmp a, b b d2 The second compa

Re: [GCC][PATCH] arm: Remove duplicate definitions from arm_mve.h (pr100419).

On 05/05/2021 10:56, Srinath Parvathaneni via Gcc-patches wrote: Hi All, This patch removes several duplicated intrinsic definitions from arm_mve.h mentioned in PR100419 and also fixes the wrong arguments in few of intrinsics polymorphic variants. Regression tested and found no issues. Ok f

<    1   2   3   4   >