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
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
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
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
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
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.
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
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
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-effe
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
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
ches <
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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:
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
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
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/
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
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
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
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
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
@ unaligned
ldr r1, [r3, #4]@ unaligned
bx lr
R.
Richard Earnshaw (3):
rtl: directly handle MEM in gen_highpart [PR102125]
arm: expand handling of movmisalign for DImode [PR102125]
gimple: allow more folding of memcpy [PR102125]
gcc/config/arm/arm.
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
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
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
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
propriate integer mode.
With these three changes, the testcase above now optimizes to
mov r3, r0
ldr r0, [r0]@ unaligned
ldr r1, [r3, #4]@ unaligned
bx lr
R.
Richard Earnshaw (3):
rtl: properly handle subreg (mem) in gen_highpart
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
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
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
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
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
unaligned
bx lr
R.
Richard Earnshaw (3):
rtl: allow forming subregs of already unaligned mems [PR102125]
arm: expand handling of movmisalign for DImode [PR102125]
gimple: allow more folding of memcpy [PR102125]
gcc/config/arm/arm.md| 34 ++
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
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
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
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.
*
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/
test suite. The remaining patches then implement the mitigation
itself and add some additional tests to the testsuite.
I will also back-port this series to gcc-10 and gcc-11.
R.
Richard Earnshaw (6):
arm: Fix general issues with patterns for VLLDM and VLSTM
arm: testsuite: improve detection
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
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
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
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
mean
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
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 .
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
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
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 targ
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
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 .
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
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
gh
several configurations, it's possible that this may have some impact
on the testsuite that I've missed. Christophe, is the any chance you
can run this through your test environment before I commit this?
R.
Richard Earnshaw (3):
arm: ensure the arch_name is always set for the build target
ar
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
>>&
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
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
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
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
--
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
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
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
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
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
On 30/06/2021 05:47, Martin Liška wrote:
On 6/29/21 12:50 PM, Richard Earnshaw wrote:
On 29/06/2021 11:09, Martin Liška wrote:
On 6/28/21 5:33 PM, Joseph Myers wrote:
Are formatted manuals (HTML, PDF, man, info) corresponding to this
patch
version also available for review?
I've
On 29/06/2021 11:09, Martin Liška wrote:
On 6/28/21 5:33 PM, Joseph Myers wrote:
Are formatted manuals (HTML, PDF, man, info) corresponding to this patch
version also available for review?
I've just uploaded them here:
https://splichal.eu/gccsphinx-final/
Martin
In the HTML version of t
On 14/06/2021 11:34, Srinath Parvathaneni via Gcc-patches wrote:
Hi,
The current CMSE support in the multilib build for
"-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken
as specified in PR99939 and this patch fixes the issue.
Regression tested on arm-none-eabi and found no re
On 14/06/2021 11:34, Srinath Parvathaneni via Gcc-patches wrote:
Hi,
The current CMSE support in the multilib build for
"-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken
as specified in PR99939 and this patch fixes the issue.
Regression tested on arm-none-eabi and found no regre
On 14/06/2021 15:29, Srinath Parvathaneni via Gcc-patches wrote:
Hi Richard,
I have all addressed all your review comments (in [1]) in the below patch.
On passing +cdecp[0-7] extension to the -march string in command line options,
multilib linking is failing as mentioned in PR100856. This pa
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
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
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
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
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
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
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
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
13:22, Srinath Parvathaneni via Gcc-patches wrote:
Ping!!
-Original Message-
From: Srinath Parvathaneni
Sent: 30 April 2021 16:24
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov ; Richard Earnshaw
Subject: [GCC-10 backport][PATCH] arm: _Generic feature failing with ICE for
-O0 (pr97205
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
On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
Normally we expect the gimple optimizers to fold away comparisons that
are always true, but at some lower optimization levels this is not
always the case, so the back-end has to be
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 TARGET_HAVE_FPCXT_CMSE. As it stands,
the expander (arm.md:nonsecure_call_internal) moves the callee's address
to a register (with
On 14/05/2021 04:36, Prathamesh Kulkarni wrote:
> On Wed, 12 May 2021 at 20:33, Richard Earnshaw
> wrote:
>>
>> On 12/05/2021 12:05, Prathamesh Kulkarni via Gcc-patches wrote:
>>> On Wed, 12 May 2021 at 16:02, Richard Earnshaw
>>> wrote:
>>>>
On 12/05/2021 10:56, Srinath Parvathaneni via Gcc-patches wrote:
Hi,
This is a backport to GCC-10 branch, this patch got applied cleanly on the
branch.
This patch removes several duplicated intrinsic definitions from
arm_mve.h mentioned in PR100419 and also fixes the wrong arguments
in few
On 12/05/2021 10:56, Srinath Parvathaneni via Gcc-patches wrote:
Hi,
This is a backport to GCC-11 branch, this patch got applied cleanly on the
branch.
This patch removes several duplicated intrinsic definitions from
arm_mve.h mentioned in PR100419 and also fixes the wrong arguments
in few
401 - 500 of 2674 matches
Mail list logo
