On 03/10/2023 16:18, Victor Do Nascimento wrote:
This patch adds the `aarch64-sys-regs.def' file to GCC, teaching
the compiler about system registers known to the assembler and how
these can be used.
The macros used to hold system register information reflect those in
use by binutils, a desig
On 03/10/2023 16:18, Victor Do Nascimento wrote:
This patch defines the structure of a new .def file used for
representing the aarch64 system registers, what information it should
hold and the basic framework in GCC to process this file.
Entries in the aarch64-system-regs.def file should be a
On 03/10/2023 16:18, Victor Do Nascimento wrote:
Given the implementation of a mechanism of encoding system registers
into GCC, this patch provides the mechanism of validating their use by
the compiler. In particular, this involves:
1. Ensuring a supplied string corresponds to a known sys
On 03/10/2023 16:18, Victor Do Nascimento wrote:
Motivated by the need to print system register names in output
assembly, this patch adds the required logic to
`aarch64_print_operand' to accept rtxs of type CONST_STRING and
process these accordingly.
Consequently, an rtx such as:
(set (re
On 03/10/2023 16:18, Victor Do Nascimento wrote:
Implement the aarch64 intrinsics for reading and writing system
registers with the following signatures:
uint32_t __arm_rsr(const char *special_register);
uint64_t __arm_rsr64(const char *special_register);
void* __arm_r
On 03/10/2023 16:18, Victor Do Nascimento wrote:
In implementing the ACLE read/write system register builtins it was
observed that leaving argument type checking to be done at expand-time
meant that poorly-formed function calls were being "fixed" by certain
optimization passes, meaning bad cod
On 05/10/2023 13:26, Richard Earnshaw wrote:
On 03/10/2023 16:18, Victor Do Nascimento wrote:
Motivated by the need to print system register names in output
assembly, this patch adds the required logic to
`aarch64_print_operand' to accept rtxs of type CONST_STRING and
process
On 28/09/2023 14:26, Richard Ball wrote:
For normal optimization for the Arm state in gcc we get an uncompressed
table of jump targets. This is in the middle of the text segment
far larger than necessary, especially at -Os.
This patch compresses the table to use deltas in a similar manner to
T
On 28/09/2023 14:29, Richard Ball wrote:
Follow up patch to arm: Use deltas for Arm switch tables
This patch moves the switch tables for Arm from the .text section
into the .rodata section.
gcc/ChangeLog:
* config/arm/aout.h: Change to use the Lrtx label.
* config/arm/arm.h (
lf. There
appear to be a number of tricky issues with more complex edges so I'd
like a second opinion on that code in case I've missed an important
case.
R.
Richard Earnshaw (7):
Add __builtin_speculation_safe_value
Arm - add speculation_barrier pattern
AArch64 - add speculati
This patch defines a speculation barrier for AArch32.
* config/arm/unspecs.md (unspecv): Add VUNSPEC_SPECULATION_BARRIER.
* config/arm/arm.md (speculation_barrier): New expand.
(speculation_barrier_insn): New pattern.
---
gcc/config/arm/arm.md | 21 +++
Similar to Arm, this adds an unconditional speculation barrier for AArch64.
* config/aarch64.md (unspecv): Add UNSPECV_SPECULAION_BARRIER.
(speculation_barrier): New insn.
---
gcc/config/aarch64/aarch64.md | 10 ++
1 file changed, 10 insertions(+)
diff --git a/gcc/config
This patch doesn't do anything useful, it simply adds a new command-line
option -mtrack-speculation to AArch64. Subsequent patches build on this.
* config/aarch64/aarch64.opt (mtrack-speculation): New target option.
---
gcc/config/aarch64/aarch64.opt | 4
1 file changed, 4 insertio
This patch defines a new intrinsic function
__builtin_speculation_safe_value. A generic default implementation is
defined which will attempt to use the backend pattern
"speculation_safe_barrier". If this pattern is not defined, or if it
is not available, then the compiler will emit a warning, bu
In this final patch, now that we can track speculation through conditional
branches, we can use this information to use a less expensive CSDB based
speculation barrier.
* config/aarch64/iterators.md (ALLI_TI): New iterator.
* config/aarch64/aarch64.md (despeculate_copy): New
This patch is the main part of the speculation tracking code. It adds
a new target-specific pass that is run just before the final branch
reorg pass (so that it can clean up any new edge insertions we make).
The pass is only run with -mtrack-speculation is passed on the command
line.
One thing t
The CB[N]Z and TB[N]Z instructions do not expose the comparison through
the condition code flags. This makes it impossible to track speculative
execution through such a branch. We can handle this relatively easily
by simply disabling the patterns in this case.
A side effect of this is that the
Similar to Arm, this adds an unconditional speculation barrier for AArch64.
* config/aarch64.md (unspecv): Add UNSPECV_SPECULAION_BARRIER.
(speculation_barrier): New insn.
---
gcc/config/aarch64/aarch64.md | 10 ++
1 file changed, 10 insertions(+)
diff --git a/gcc/config
ew from
someone more familiar with the branch edge code than myself. There
appear to be a number of tricky issues with more complex edges so I'd
like a second opinion on that code in case I've missed an important
case.
R.
Richard Earnshaw (11):
Add __builtin_speculation_safe_value
This patch defines a speculation barrier for AArch32.
* config/arm/unspecs.md (unspecv): Add VUNSPEC_SPECULATION_BARRIER.
* config/arm/arm.md (speculation_barrier): New expand.
(speculation_barrier_insn): New pattern.
---
gcc/config/arm/arm.md | 21 +++
This patch is the main part of the speculation tracking code. It adds
a new target-specific pass that is run just before the final branch
reorg pass (so that it can clean up any new edge insertions we make).
The pass is only run with -mtrack-speculation is passed on the command
line.
One thing t
This patch defines a new intrinsic function
__builtin_speculation_safe_value. A generic default implementation is
defined which will attempt to use the backend pattern
"speculation_safe_barrier". If this pattern is not defined, or if it
is not available, then the compiler will emit a warning, bu
In this final patch, now that we can track speculation through conditional
branches, we can use this information to use a less expensive CSDB based
speculation barrier.
* config/aarch64/iterators.md (ALLI_TI): New iterator.
* config/aarch64/aarch64.md (despeculate_copy): New
This patch is intended as an example of all that is needed if the
target system doesn't support CPUs that have speculative execution.
I've chosen the pdp11 port on the basis that it's old enough that this
is likely to be true for all existing implementations and that there
is also little chance of
This patch adds a speculation barrier for x86, based on my
understanding of the required mitigation for that CPU, which is to use
an lfence instruction.
This patch needs some review by an x86 expert and if adjustments are
needed, I'd appreciate it if they could be picked up by the port
maintainer
This hook adds an alternative implementation for the target hook
TARGET_HAVE_SPECULATION_SAFE_VALUE; it can be used by targets that have no
CPU implementations that execute code speculatively. All that is needed for
such targets now is to add:
#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
#define
The CB[N]Z and TB[N]Z instructions do not expose the comparison through
the condition code flags. This makes it impossible to track speculative
execution through such a branch. We can handle this relatively easily
by simply disabling the patterns in this case.
A side effect of this is that the
This patch doesn't do anything useful, it simply adds a new command-line
option -mtrack-speculation to AArch64. Subsequent patches build on this.
* config/aarch64/aarch64.opt (mtrack-speculation): New target option.
---
gcc/config/aarch64/aarch64.opt | 4
1 file changed, 4 insertio
This patch reworks the existing rs6000_speculation_barrier pattern to
work with the new __builtin_sepculation_safe_value() intrinsic. The
change is trivial as it simply requires renaming the existing speculation
barrier pattern.
So the total patch is to delete 14 characters!
* config/rs
On 19/10/2023 13:43, Wilco Dijkstra wrote:
Further improve immediate generation by adding support for 2-instruction
MOV/EOR bitmask immediates. This reduces the number of 3/4-instruction
immediates in SPECCPU2017 by ~2%.
Passes regress, OK for commit?
gcc/ChangeLog:
* config/aarch64
On 20/10/2023 13:13, Richard Sandiford wrote:
+(define_insn_and_split "*cmov_insn_insv"
+ [(set (match_operand:GPI 0 "register_operand" "=r")
+(xor:GPI
+(neg:GPI
+ (match_operator:GPI 1 "aarch64_comparison_operator"
+ [(match_operand 2 "cc_register" "") (const
On 02/10/2023 18:12, Wilco Dijkstra wrote:
Hi Ramana,
I used --target=arm-none-linux-gnueabihf --host=arm-none-linux-gnueabihf
--build=arm-none-linux-gnueabihf --with-float=hard. However it seems that the
default armhf settings are incorrect. I shouldn't need the --with-float=hard
since
tha
On 08/09/2023 09:43, Christophe Lyon via Gcc-patches wrote:
The test was declaring 'int *carry;' and wrote to '*carry' without
initializing 'carry' first, leading to an attempt to write at address
zero, and a crash.
Fix by declaring 'int carry;' and passing '&carrry' instead of 'carry'
as par
On 24/10/2023 16:53, Iain Sandoe wrote:
Although this came up initially when working on the Darwin Arm64
port, it also breaks cross-compilers on platforms with non-GNU sed.
Tested on x86_64-darwin X aarch64-linux-gnu, aarch64-darwin,
aarch64-linux-gnu and x86_64-linux-gnu. OK for master?
tha
On 24/10/2023 18:27, Wilco Dijkstra wrote:
v2: Use check-function-bodies in tests
Further improve immediate generation by adding support for 2-instruction
MOV/EOR bitmask immediates. This reduces the number of 3/4-instruction
immediates in SPECCPU2017 by ~2%.
Passes regress, OK for commit?
On 27/10/2023 15:55, Richard Ball wrote:
v2: Formatting and nits fixed.
Follow up patch to arm: Use deltas for Arm switch tables
This patch moves the switch tables for Arm from the .text section
into the .rodata section.
gcc/ChangeLog:
* config/arm/aout.h: Change to use the Lrtx lab
On 28/10/2019 21:52, Bernhard Reutner-Fischer wrote:
> On Mon, 28 Oct 2019 11:53:06 +1100
> Kugan Vivekanandarajah wrote:
>
>> On Wed, 23 Oct 2019 at 23:07, Richard Biener
>> wrote:
>
>>> Did you try this with multiple assembler options? I see you stream
>>> them as -Wa,-mfpu=xyz,-mthumb but
On 14/01/2020 13:37, Jonathan Wakely wrote:
> I really think people should be reviewing what they're about to push
> before doing it.
>
> OK for wwwdocs?
>
I'd recommend
git push origin HEAD:
rather than just 'git push'
Otherwise, OK.
R.
On 14/01/2020 13:18, Jonathan Wakely wrote:
> OK for wwwdocs?
>
>
OK.
The peephole that detects a mov of one register to another followed by
a comparison of the original register against zero is only used in Arm
state; but the instruction that matches this is generic to all 32-bit
compilation states. That instruction lacks support for SP which is
permitted in Arm s
For thumb1, when using a peephole to fuse
mov reg, #const
add reg, reg, SP
into
add reg, SP, #const
we must first check that reg is a low register, otherwise we will ICE
when trying to recognize the resulting insn.
gcc/ChangeLog:
PR target/113510
* con
This test generates different warnings on ilp32 targets because the size
of an integer matches the size of a pointer. Avoid this by using
signed char.
gcc/testsuite:
PR testsuite/113428
* gcc.dg/gomp/bad-array-section-c-3.c: Use signed char instead
of int.
---
I think t
This test was too simple, which meant that the compiler was sometimes
able to find a better optimization of the code than using a BICS
instruction. Fix this by changing the test slightly to produce a
sequence where BICS should always be the preferred solution.
gcc/testsuite:
PR target/11
On 13/03/2024 10:58, Maxim Kuvyrkov wrote:
This patch has been tested on
- aarch64-linux-gnu
- arm-linux-gnueabihf (VFP, NEON disabled by default),
- arm-none-eabi (Soft-FP)
with the following [expected] differences in the test results:
- FAIL now PASS [FAIL => PASS]:
Execut
On 12/03/2024 14:08, Richard Ball wrote:
The SCHEDULER_IDENT for this CPU was incorrectly
set to cortexa55, which is incorrect. This can cause
sub-optimal asm to be generated.
Ok for trunk?
gcc/ChangeLog:
PR target/114272
* config/aarch64/aarch64-cores.def (AARCH64_CORE):
On 13/03/2024 12:12, Maxim Kuvyrkov wrote:
Changes in v2:
- Better changelog entry.
- NFC.
This patch has been tested on
- aarch64-linux-gnu
- arm-linux-gnueabihf (VFP, NEON disabled by default),
- arm-none-eabi (Soft-FP)
with the following [expected] differences in the test results:
- F
The v*_fp16_xN_1.c tests on Arm have been unstable since they were
added. This is not a problem with the tests themselves, or even the
patches that were added, but with the testsuite infrastructure. It
turned out that another set of dg- tests for fp16 were corrupting the
cached set of options us
On 13/02/2024 10:44, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-13?
The alternative approach (that is changing the result a bit) is to drop
the special treatment for arm*-*-*. I'm not sure if this is prefered or
just disable the test for incompatible flags for arm*-*-*.
--
The t
The expand pattern for reciprocal division was enabled for all math
optimization modes, but the patterns it was generating were not
enabled unless -funsafe-math-optimizations were enabled, this leads to
an ICE when the pattern we generate cannot be recognized.
Fixed by only enabling vector divisi
GCC 13's changes file documents that iwmmx is deprecated. Raise the bar
by warning when the mmintrin.h header is included by users, but provide
a way to suppress the warning.
gcc:
* config/arm/mmintrin.h: Warn if this header is included without
defining __ENABLE_DEPRECATED_IWMMXT
On 09/01/2023 10:32, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> On powerpc64le-linux, the following patch fixes
> -FAIL: gcc.dg/c2x-stdarg-4.c execution test
> -FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O0 execution test
> -FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O1 execution te
[resending, apologies, I accidentally CC'd the wrong person last time]
On 27/02/2024 16:41, Richard Earnshaw wrote:
>
>
> On 09/01/2023 10:32, Jakub Jelinek via Gcc-patches wrote:
>> Hi!
>>
>> On powerpc64le-linux, the following patch fixes
>> -FAIL
On 29/02/2024 14:10, Richard Earnshaw (lists) wrote:
> On 27/02/2024 17:25, Jakub Jelinek wrote:
>> On Tue, Feb 27, 2024 at 04:41:32PM +, Richard Earnshaw wrote:
>>>> 2023-01-09 Jakub Jelinek
>>>>
>>>>PR target/107453
>
On 05/01/2024 01:43, Lipeng Zhu wrote:
This patch try to fix the bug when HAVE_ATOMIC_FETCH_ADD is
not defined in dec_waiting_unlocked function. As io.h does
not include async.h, the WRLOCK and RWUNLOCK macros are
undefined.
libgfortran/ChangeLog:
* io/io.h (dec_waiting_unlocked): Use
On 08/01/2024 17:21, Matthieu Longo wrote:
Hi,
Arm GCC backend does not define __ARM_FEATURE_BF16 when +bf16 is
specified (via -march option, or target pragma) whereas it is supposed
to be tested before including arm_bf16.h (as specified in ACLE document:
https://arm-software.github.io/acl
On 08/01/2024 16:07, Roger Sayle wrote:
Bootstrapping GCC on arm-linux-gnueabihf with --with-arch=armv6 currently
has a large number of FAILs in libatomic (regressions since last time I
attempted this). The failure mode is related to IFUNC handling with the
file tas_8_2_.o containing an unre
y and pushed this.
Could you please prepare backports for gcc-11 thru 13? It should just
be a matter of cherry-picking the commit.
R.
On 2024-01-22 16:25, Richard Earnshaw (lists) wrote:
On 22/01/2024 12:18, Matthieu Longo wrote:
rev16 pattern was not recognised anymore as a change in the
On 15/12/2023 11:31, Lipeng Zhu wrote:
On 2023/12/14 23:50, Richard Earnshaw (lists) wrote:
On 09/12/2023 15:39, Lipeng Zhu wrote:
This patch try to introduce the rwlock and split the read/write to
unit_root tree and unit_cache with rwlock instead of the mutex to
increase CPU efficiency
On 30/11/2023 10:15, Christophe Lyon wrote:
After commit r14-5617-gb8592186611, int32x[24]_t types now use
elements of 'long int' type instead of 'int' on arm-eabi (it's still
'int' on arm-linux-gnueabihf). Both are 32-bit types anyway.
This patch adjust the two tests so that they optionnall
On 29/11/2023 18:09, Richard Sandiford wrote:
Wilco Dijkstra writes:
v2: Use UINTVAL, rename max_mops_size.
The cpymemdi/setmemdi implementation doesn't fully support strict alignment.
Block the expansion if the alignment is less than 16 with STRICT_ALIGNMENT.
Clean up the condition when to
On 30/11/2023 08:27, Di Zhao OS wrote:
This patch modifies tunings for ampere1/ampere1a/ampere1b, to:
1. Allow reassociation on FP additions.
2. Avoid generating loop-dependant FMA chains. Added a tuning
option for this.
Bootstrapped and tested. Is this ok for trunk?
Thanks,
Di Zhao
gcc/Ch
ns "-Wc++-compat" } */
+/* { dg-options "-fpermissive -Wc++-compat" } */
typedef struct A { int i; } B;
typedef struct T { int i; } *T; /* { dg-warning "using 'T' as both a typedef and a
tag is invalid" } */
diff --git a/gcc/testsuite/gcc.dg/diag-aka-1a
On 05/12/2023 09:46, Florian Weimer wrote:
* Richard Earnshaw:
(I think it's this patch, not one of the others in the series).
This breaks building libgfortran with newlib on arm and aarch64:
/work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/list_read.c:2208:46:
On 05/12/2023 10:33, Jakub Jelinek wrote:
Hi!
On Tue, Dec 05, 2023 at 10:46:02AM +0100, Florian Weimer wrote:
Presumably the fixes will look like this?
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index db3330060ce..4fcc77dbf83 100644
--- a/libgfortran/io/list_read.c
On 05/12/2023 10:51, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote:
The following patch makes libgfortran build on i686-linux after hacking up
--- kinds.h.xx 2023-12-05 00:23:00.133365064 +0100
+++ kinds.h 2023-12-05 11:19:24.409679808 +0100
On 05/12/2023 10:59, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 10:57:50AM +, Richard Earnshaw wrote:
On 05/12/2023 10:51, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote:
The following patch makes libgfortran build on i686-linux after hacking up
Sorry, I only just spotted this while looking at something else.
On 23/05/2023 15:41, Christophe Lyon via Gcc-patches wrote:
Glibc defines int32_t as 'int' while newlib defines it as 'long int'.
Although these correspond to the same size, g++ complains when using the
On 03/11/2023 15:36, Szabolcs Nagy wrote:
Refactor the parsing to have a single API and fix a few parsing issues:
- Different handling of "bti+none" and "none+bti": these should be
rejected because "none" can only appear alone.
- Accepted empty strings such as "bti++pac-ret" or "bti+", th
On 03/11/2023 15:36, Szabolcs Nagy wrote:
The branch-protection types are target specific, not the same on arm
and aarch64. This currently affects pac-ret+b-key, but there will be
a new type on aarch64 that is not relevant for arm.
gcc/ChangeLog:
* config/aarch64/aarch64-opts.h (enu
Pushed, thanks.
R.
On 07/12/2023 15:28, ezra.sito...@arm.com wrote:
Add xN variants of vst1_types intrinsic.
Pushed, thanks.
R.
On 07/12/2023 15:36, ezra.sito...@arm.com wrote:
Add xN variants of vst1q_types intrinsic.
Pushed, thanks.
R.
On 07/12/2023 15:41, ezra.sito...@arm.com wrote:
Add xN variants of vld1_types intrinsic.
Sorry, Ezra, but I've taken the decision to back out all 4 of the patch
series' related to this. I think the problems that the CI has shown up
need to be addressed first, and the fixes don't seem to be entirely trivial.
R.
On 07/12/2023 16:44, Richard Earnshaw wrote:
Pus
On 06/11/2023 11:20, Stamatis Markianos-Wright wrote:
Patch has already been approved at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630326.html
... But I'm sending this again for archiving on the list after rebasing
A couple of minor nits:
1)
+#define MVE_VPT_PREDICABLE_I
Pushed, thanks.
R.
On 07/12/2023 15:21, ezra.sito...@arm.com wrote:
Add xN variants of vld1q_types intrinsic.
e (Arm)
Thank you :)
LGTM otherwise (but I don't have the power to approve this ;)).
Kind regards,
Andre
From: Stamatis Markianos-Wright
Sent: Thursday, November 16, 2023 11:36 AM
To: Stamatis Markianos-Wright via Gcc-patches; Richard Earnshaw;
Richard Sandifor
On 10/11/2023 10:17, Wilco Dijkstra wrote:
Hi Kyrill,
+ /* Reduce the maximum size with -Os. */
+ if (optimize_function_for_size_p (cfun))
+ max_set_size = 96;
+
This is a new "magic" number in this code. It looks sensible, but how did
you arrive at it?
We need 1 instruction
On 10/11/2023 14:46, Kyrylo Tkachov wrote:
-Original Message-
From: Richard Earnshaw
Sent: Friday, November 10, 2023 11:31 AM
To: Wilco Dijkstra ; Kyrylo Tkachov
; GCC Patches
Cc: Richard Sandiford ; Richard Earnshaw
Subject: Re: [PATCH] AArch64: Cleanup memset expansion
On
flict.
I have some ideas about how to address this, but that's for a later
test series.
committed to master branch.
R.
Richard Earnshaw (22):
arm: testsuite: correctly detect armv6t2 hardware for acle execution
tests
arm: testsuite: correctly detect hard_float
arm: testsuite: avoi
Some of the ACLE tests for Arm are executable, but we were only testing
that the compiler could generate code for them, not that the hardware
was capable of executing them. Fix this by adding an execution test for
suitable hardware.
gcc/testsuite:
* lib/target-supports.exp (check_effect
Add an arm-specific test to check_effective_target_hard_float for
Arm to handle cases where we only have single-precision FP in hardware.
gcc/testsuite:
* lib/target-supports.exp (check_effective_target_hard_float): Add
arm-specific test.
---
gcc/testsuite/lib/target-supports.ex
gcc.target/arm/g2.c is an xscale-only test, but the test is quite old
and we have improved the infrastructure for setting up such tests now.
So make use of that to reduce the number of cases where this test fails
to run.
gcc/testsuite:
* lib/target-supports.exp (check_effective_target_ar
Again, use the infrastructure available to improve the compatibility
of these tests.
gcc/testsuite:
* gcc.target/arm/pr78353-1.c: Use dg-add-options to manage target
flags.
* gcc.target/arm/pr78353-2.c: Likewise.
---
gcc/testsuite/gcc.target/arm/pr78353-1.c | 3 ++-
gcc/
This test overrides the architecture, but fails to describe which
floating-point features are needed. This causes problems if the ABI
requires FP for parameter passing and -mfpu=auto is selected, so ensure
that one is specified.
gcc/testsuite:
* gcc.target/arm/acle/pacbti-m-predef-11.c:
A number of tests in the gcc testsuite, especially for arm-specific
targets, add various flags to control the architecture. These run
into problems when the compiler is configured with -mfpu=auto if the
new architecture lacks an architectural feature that implies we have
floating-point instructio
This test overrides the architecture, but fails to describe which
floating-point features are needed. This causes problems if the ABI
requires FP for parameter passing and -mfpu=auto is selected, so ensure
that one is specified.
gcc/testsuite:
* gcc.target/arm/attr_thumb-static2.c: Add
Fix another test that was trying to set the architecture directly
rather than using the infrastructure as intended.
gcc/testsuite:
* gcc.target/arm/pr88648-asm-syntax-unified.c: It isn't necessary
to try to override the architecture flags specified by arm_arch_v7a.
---
gcc/tests
These tests deliberately pass invalid option combinations to check
that the compiler is generating the correct diagnostic. Nevertheless,
we can improve their compatibility with other testsuite options. For
optional_thumb-1.c we use a soft-float ABI, while for
optional_thumb2.c we use arm_arch_v7
This test overrides the architecture, but fails to describe which
floating-point features are needed. This causes problems if the ABI
requires FP for parameter passing and -mfpu=auto is selected, so ensure
that one is specified.
gcc/testsuite:
* gcc.target/arm/attr-crypto.c: Add +simd t
This test overrides the architecture, but fails to specify the
floating point architecture. This causes problems if -mfpu=auto is
used.
gcc/testsuite:
* gcc.target/arm/lto/pr96939_1.c: Add +simd to the architecture
specification.
---
gcc/testsuite/gcc.target/arm/lto/pr96939_1.c
These tests use pragmas adn attributes to change the architecture.
Sometimes they simply add a feature using "+crc", but other times they
try to completely reset the architecture using "arch=armv8-a+crc".
The latter fails on a hard-float ABI with -mfpu=auto because it also
clears the FP capability
Make this test more useful by using dg-require-effective-target/
dg-add-options.
gcc/testsuite:
* gcc.target/arm/scd42-2.c: Use modern dg- flags.
---
gcc/testsuite/gcc.target/arm/scd42-2.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/gcc.tar
This test was explicitly setting the architecture on the command-line and
in the body of the test. In both cases this causes problems with the auto
FPU setting. Fix by using the testsuite infrastructure correctly and by
adding +fp to the pragma.
gcc/testsuite:
* gcc.target/arm/pragma_a
Another case where we can make better use of the infrastructure to
improve the compatibility of this test.
gcc/testsuite:
* gcc.target/arm/pr65647-2.c: Use dg-add-options to manage target
flags.
---
gcc/testsuite/gcc.target/arm/pr65647-2.c | 3 ++-
1 file changed, 2 insertions(+
Use dg-require-effective-target/dg-add-options to improve
compatibility of this test with various compiler configurations.
gcc/testsuite:
* gcc.target/arm/pr59575.c: Use dg-require-effective-target and
dg-add-options.
---
gcc/testsuite/gcc.target/arm/pr59575.c | 4 +++-
1 file c
Some of the standard Arm architecture tests require the test to use a
specific instruction set (arm or thumb). But although the framework
was checking that the flag was accepted, it wasn't checking that the
flag wasn't somehow being override (eg by run-specific options). We
can improve these tes
Convert these tests to use dg-add-options for increased compatibilty.
Since they also result in an empty translation unit, override the
default testsuite options.
gcc/testsuite:
* gcc.target/arm/macro_defs0.c: Use dg-effective-target and
dg-add-options.
* gcc.target/arm/m
This test is specific to armv7m cores which do not support hardware
floating-point. We can improve its compatibility by having the default
options for this core specify -mfloat-abi=soft.
gcc/testsuite:
* lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
Use soft
Add +fp to the architecture specification, so that -mfpu=auto works
with the hard-float ABI.
gcc/testsuite:
* gcc.target/arm/pr19599.c: Add +fp to the architecture.
---
gcc/testsuite/gcc.target/arm/pr19599.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsui
This test is arm specific and requires neon. To improve compatibility
add a new test for armv7-a with neon and use that.
gcc/testsuite:
* lib/target-supports.exp (v7a_neon): New feature-test target.
* gcc.dg/debug/pr57351.c: Use it.
---
gcc/testsuite/gcc.dg/debug/pr57351.c | 7
1 - 100 of 2973 matches
Mail list logo
