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
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
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 ++
gcc/config/arm
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
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
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.
*
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
the 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
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
*
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
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
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
Thanks, Christophe, I've updated the testsuite to fix all the issues I could
see from your test runs.
This is what I've finally committed, but if there's any more fallout, please
let me know.
R.
Richard Earnshaw (3):
arm: ensure the arch_name is always set for the build target
arm: Don't
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
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
arm: Don't reconfigure
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
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
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 to 70) so
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
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
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
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.
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 just
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
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
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
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
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
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
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
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
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
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
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
Fix a warning when building on machines that don't have 32-bit pointers
gcc/testsuite:
PR target/100563
* gcc.dg/pr100563.c (dg-options): Add -wno-pointer-to-int-cast.
---
gcc/testsuite/gcc.dg/pr100563.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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 able to generate correct
code in these cases.
In this example, we have a comparison of the form
(unsigned long
On 22/04/2021 14:32, Christophe Lyon via Gcc-patches wrote:
The test requires an FPU, so use -march=armv7-a+fp -mfpu=auto instead
of -march=armv7-a.
We also remove dg-require-effective-target arm_fp_ok, but keep
dg-add-options arm_fp: this enables the test to pass on arm-eabi
configured with
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 08:46, Prathamesh Kulkarni via Gcc-patches wrote:
>>> On Mon, 10 May 2021 at 19:55, Richard Earnshaw
>>&
On 12/05/2021 09:51, Christophe Lyon via Gcc-patches wrote:
arm.h has had this error message since 1997, but it is no longer
needed since option parsing has been improved: -mXXX-endian is handled
via arm.opt and updates the BIG_END mask. So, the last
instance of -mXXX-endian on the command
On 12/05/2021 08:46, Prathamesh Kulkarni via Gcc-patches wrote:
On Mon, 10 May 2021 at 19:55, Richard Earnshaw
wrote:
On 06/05/2021 01:14, Prathamesh Kulkarni via Gcc-patches wrote:
Hi,
The attached patch replaces __builtin_neon_vtst* (a, b) with (a & b) != 0.
Bootstrapped and te
On 06/05/2021 09:27, Alex Coplan via Gcc-patches wrote:
Hi all,
The PR shows us attaching REG_CFA_ADJUST_CFA notes to stack pointer
adjustments emitted in cmse_nonsecure_call_inline_register_clear (when
-march=armv8.1-m.main). However, the stack pointer is not guaranteed to
be the CFA reg.
On 22/04/2021 08:01, Christophe Lyon via Gcc-patches wrote:
arm.h has had this error message since 1997, and was never updated to
take softfp into account. Anyway, it seems it was useful long ago, but
it is no longer needed since option parsing has been improved:
-mfloat-abi is handled via
On 06/05/2021 01:14, Prathamesh Kulkarni via Gcc-patches wrote:
Hi,
The attached patch replaces __builtin_neon_vtst* (a, b) with (a & b) != 0.
Bootstrapped and tested on arm-linux-gnueabihf and cross-tested on arm*-*-*.
OK to commit ?
Thanks,
Prathamesh
You're missing the ChangeLog
On 05/05/2021 13:39, Srinath Parvathaneni via Gcc-patches wrote:
Hi Richard,
-Original Message-
From: Richard Earnshaw
Sent: 05 May 2021 11:15
To: Srinath Parvathaneni ; gcc-
patc...@gcc.gnu.org
Cc: Richard Earnshaw
Subject: Re: [GCC][PATCH] arm: Remove duplicate definitions from
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
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
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
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
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
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
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
From: Richard Earnshaw
This is a partial revert of r11-8168. The overall purpose of the
commit is retained (to fix a bogus warning when -mfpu= is
used in combination with eg -mcpu=neoverse-v1), but it removes the
hunk that changed the subsequent feature bits for features of a
simd/fp unit
Commit r11-8168 changed the word ordering of a warning in order to
make the text more consistent. Unfortunately, it neglected to update
some filters in the testsuite that are intended to strip such warnings
when we try to partially override the user-supplied command-line
options.
This patch
If the compiler is configured with --with-fpu= (or invoked
with, say, -mfpu=neon), then specifying -mcpu=neoverse-n1 can lead to
an unexpected warning: cc1: warning: switch ‘-mcpu=neoverse-n1’
conflicts with ‘-march=armv8.2-a’ switch
The fix for this is to correctly remove all the feature bits
On 12/04/2021 14:04, 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
On 01/04/2021 17:11, Alex Coplan via Gcc-patches wrote:
Hi all,
This patch fixes PR99748 which shows us trying to pass the argument to
__aeabi_f2iz in the VFP register s0 when the library function is
expecting to use the GPR r0. It also fixes the __aeabi_f2uiz case which
was broken in the
to pass FP arguments.
This patch removes the condition on (! TARGET_SOFT_FLOAT) because this
is a case where TARGET_SOFT_FLOAT is true, and TARGET_HARD_FLOAT_ABI
is true too.
2021-03-30 Richard Earnshaw
gcc/
PR target/99773
* config/arm/arm.c (arm_file_start): Fi
On 26/03/2021 15:35, Christophe Lyon via Gcc-patches wrote:
> Hi,
>
> I'm seeing random scan-assembler-times failures in pr96770.c when LTO is used.
>
> I suspect this is because the \\+4 string matches the LTO sections, sometimes.
>
> I propose this small patch to avoid the issue, by matching
Fix a signed vs unsigned comparison in last change.
gcc:
* common/config/arm/arm-common.c (arm_config_default): Change type
of 'i' to unsigned.
---
gcc/common/config/arm/arm-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 03/03/2021 14:11, Christophe Lyon via Gcc-patches wrote:
> On Wed, 3 Mar 2021 at 14:55, Richard Earnshaw (lists)
> wrote:
>>
>> Hopefully this change will reduce the number of times Christophe is
>> needing to tweak the testsuite.
>>
>
> Thanks!
>
On 02/03/2021 18:35, Christophe Lyon wrote:
> On Tue, 2 Mar 2021 at 19:18, Richard Earnshaw
> wrote:
>>
>> On 02/03/2021 18:14, Richard Earnshaw via Gcc-patches wrote:
>>> On 02/03/2021 18:10, Christophe Lyon wrote:
>>>> On Tue, 2 Mar 2021 at 17:25, Richard
Hopefully this change will reduce the number of times Christophe is
needing to tweak the testsuite.
--
Arm processors can support up to two instruction sets. Some early
cores only support the traditional A32 (Arm) instructions, while some
more recent devices only support T32 (Thumb)
On 02/03/2021 18:14, Richard Earnshaw via Gcc-patches wrote:
> On 02/03/2021 18:10, Christophe Lyon wrote:
>> On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw
>> wrote:
>>>
>>> On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote:
>>>> On 01/0
On 02/03/2021 18:10, Christophe Lyon wrote:
> On Tue, 2 Mar 2021 at 17:25, Richard Earnshaw
> wrote:
>>
>> On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote:
>>> On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote:
>>>> Ping?
>>>>
On 02/03/2021 16:19, Richard Earnshaw via Gcc-patches wrote:
> On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote:
>> Ping?
>>
>> On Wed, 3 Feb 2021 at 10:01, Christophe Lyon
>> wrote:
>>>
>>> Ping?
>>> I guess that's obvious enough?
On 01/03/2021 15:26, Christophe Lyon via Gcc-patches wrote:
> Ping?
>
> On Wed, 3 Feb 2021 at 10:01, Christophe Lyon
> wrote:
>>
>> Ping?
>> I guess that's obvious enough?
>>
>> On Wed, 27 Jan 2021 at 10:03, Christophe Lyon
>> wrote:
>>>
>>> Depending on how the toolchain is configured or how
Commit r10-6017 relaxed the constraint on thumb2 calls to
__gnu_cmse_nonsecure_call to allow any register for the call address.
Although the initial code expansion continues to use r4 with the FPCXT
extension is not enabled, the change was unsafe because subsequent
optimizations could use the
On 09/12/2020 17:21, Christoph Müllner wrote:
> From: Christoph Muellner
>
> It is possible to call aarch64_declare_function_name() and
> have cfun not set. Let's sanitize the access to this variable.
>
> gcc/
>
> * config/aarch64/aarch64.c (aarch64_declare_function_name):
> Santize
On 12/02/2021 17:21, Christophe Lyon wrote:
> On Fri, 12 Feb 2021 at 17:02, Richard Earnshaw
> wrote:
>>
>> On 12/02/2021 14:20, Christophe Lyon via Gcc-patches wrote:
>>> This test forces -march=armv8.1-m.main, which supports only Thumb mode.
>>> However
On 12/02/2021 14:20, Christophe Lyon via Gcc-patches wrote:
> This test forces -march=armv8.1-m.main, which supports only Thumb mode.
> However, if the toolchain is not configured --with-thumb, the test
> fails with:
> error: target CPU does not support ARM mode
>
> Adding -mthumb to dg-options
On 10/02/2021 17:44, Andrea Corallo via Gcc-patches wrote:
> Andrea Corallo via Gcc-patches writes:
>
>> "Richard Earnshaw (lists)" writes:
>>
>>> On 09/02/2021 16:27, Andrea Corallo via Gcc-patches wrote:
>>>> Jakub Jelinek writes:
>>&
On 09/02/2021 16:27, Andrea Corallo via Gcc-patches wrote:
> Jakub Jelinek writes:
>
>> On Tue, Feb 09, 2021 at 03:09:43PM +0100, Jakub Jelinek via Gcc-patches
>> wrote:
"TARGET_32BIT && TARGET_HAVE_LOB"
- "le\t%|lr, %l0")
+ "*
+ if (get_attr_length (insn) == 4)
+
On 11/01/2021 15:58, Daniel Engel wrote:
>
> On Mon, Jan 11, 2021, at 7:39 AM, Richard Earnshaw wrote:
>> On 11/01/2021 15:26, Richard Earnshaw wrote:
>>> On 11/01/2021 11:10, g...@danielengel.com wrote:
>>>> From: Daniel Engel
>>>>
>>&g
On 11/01/2021 11:10, g...@danielengel.com wrote:
> From: Daniel Engel
>
> This version combines __ctzdi2() with __ctzsi2() into a single object with
> an efficient tail call. The former implementation of __ctzdi2() was in C.
>
> On architectures without a clz instruction, this version merges
A general comment before we start:
CLZ was added to the Arm ISA in Armv5. So all subsequent Arm versions
(and all versions implementing thumb2) will have this instruction. So
the only cases where you'll need a fallback are armv6m (and derivatives)
and pre-armv5 (Arm or thumb1). So there's no
On 11/01/2021 15:26, Richard Earnshaw wrote:
> On 11/01/2021 11:10, g...@danielengel.com wrote:
>> From: Daniel Engel
>>
>> gcc/libgcc/ChangeLog:
>> 2021-01-07 Daniel Engel
>>
>> * config/arm/lib1funcs.S: Move __clzsi2() and __clzdi2() to
>
On 11/01/2021 11:10, g...@danielengel.com wrote:
> From: Daniel Engel
>
> gcc/libgcc/ChangeLog:
> 2021-01-07 Daniel Engel
>
> * config/arm/lib1funcs.S: Move __ashldi3(), __ashrdi3(), __lshldi3() to
> * config/arm/bits/shift.S: New file.
Again, drop the bits/
R.
> ---
>
On 11/01/2021 11:10, g...@danielengel.com wrote:
> From: Daniel Engel
>
> gcc/libgcc/ChangeLog:
> 2021-01-07 Daniel Engel
>
> * config/arm/lib1funcs.S: Move __ctzsi2() to
> * config/arm/bits/ctz2.S: New file.
Similar to the previous patch, just use ctz.S without the bits subdir.
On 11/01/2021 11:10, g...@danielengel.com wrote:
> From: Daniel Engel
>
> gcc/libgcc/ChangeLog:
> 2021-01-07 Daniel Engel
>
> * config/arm/lib1funcs.S: Move __clzsi2() and __clzdi2() to
> * config/arm/bits/clz2.S: New file.
No, please don't push these down into a subdirectory.
Some initial comments.
On 11/01/2021 11:10, g...@danielengel.com wrote:
> From: Daniel Engel
>
> These definitions facilitate subsequent patches in this series.
>
> gcc/libgcc/ChangeLog:
> 2021-01-07 Daniel Engel
>
> * config/arm/t-elf: Organize functions into logical groups.
> *
401 - 500 of 2575 matches
Mail list logo
