On 08/08/2025 15:59, Andre Vieira (lists) wrote:
Fix the bound checking for the opc1 operand of the following intrinsics:
__arm_mcrr
__arm_mcrr2
__arm_mrrc
__arm_mrrc2
Built arm-none-linux-gnueabihf and ran full regression test, and built
arm-none-eabi but only ran the changed tests
On 20/05/2025 05:28, Alexandre Oliva wrote:
(The backport I've only just posted is not enough for the tests to pass;
there's another problem)
r14-10824 is a backport of r15-4549, that rewrote and extended into
check-function-bodies the save/restore expectations introduced in
r15-2160. Alas, r1
On 08/08/2025 16:56, Christophe Lyon wrote:
On Fri, 8 Aug 2025 at 16:51, Richard Earnshaw wrote:
On 26/05/2025 17:08, Christophe Lyon wrote:
This effective target implicitly expects -march=armv8-a, otherwise
with a toolchain configured for instance with
--with-cpu=cortex-m0 --with-float=soft
On 08/08/2025 16:49, Christophe Lyon wrote:
On Fri, 8 Aug 2025 at 17:04, Richard Earnshaw wrote:
On 04/07/2025 23:00, Christophe Lyon wrote:
Like we do in other effective-targets, add
"-mcpu=unset -march=armv8-a"
directly when setting et_arm_v8_neon_flags in arm_v8_neon_ok_nocache
On 04/07/2025 23:00, Christophe Lyon wrote:
Like we do in other effective-targets, add
"-mcpu=unset -march=armv8-a"
directly when setting et_arm_v8_neon_flags in arm_v8_neon_ok_nocache,
to avoid having to add these two flags in all users of arm_v8_neon_ok.
This avoids duplication and possible ty
On 04/07/2025 23:00, Christophe Lyon wrote:
A few arm effective-targets call check_effective_target_arm32 even
though they would force a -march=XXX flag which supports Arm and/or
Thumb-2, thus making the arm32 check useless. This has an impact when
the toolchain is configured with a default -mar
On 26/05/2025 17:08, Christophe Lyon wrote:
This effective target implicitly expects -march=armv8-a, otherwise
with a toolchain configured for instance with
--with-cpu=cortex-m0 --with-float=soft,
it fails even when trying
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp:
arm_neon.h:45:2: error: #er
On 11/07/2025 09:46, Torbjörn SVENSSON wrote:
Ok for trunk, gcc-15 and gcc-14.
I discovered that the dg-require-effective-target is missing on gcc-14,
but it's probably the right thing to add on gcc-15 and trunk too.
Without the `dg-require-effective-target vect_early_break`, the
`dg-add-option
On 09/07/2025 19:55, Torbjorn SVENSSON wrote:
Hi Christophe,
On 2025-07-09 17:31, Christophe Lyon wrote:
On Wed, 9 Jul 2025 at 10:25, Torbjörn SVENSSON
wrote:
Ok for trunk and releases/gcc-15?
Changes since v1:
- Removed the acceptance of LDR as it's only generated without
r15-7373-g5163cf
On 08/07/2025 16:14, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-15?
--
The scheduler allows the `and` instruction to be placed at 3 different
locations. Update the function body to contain all 3 locations.
Also, armv8.1-m.main can use `ldr` instead of `pop` to return.
gcc/testsuite
On 10/07/2025 15:08, Christophe Lyon wrote:
As discussed in https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685733.html
the operand of the call should be a mem rather than an unspec.
This patch moves the unspec to an additional argument of the parallel
and adjusts cmse_nonsecure_call_inline_
On 04/07/2025 23:04, Christophe Lyon wrote:
We get lots of error messages when compiling arm_neon.h under
e.g. -mcpu=cortex-m55, because Neon builtins are enabled only when
!TARGET_HAVE_MVE. This has been the case since MVE support was
introduced.
This patch uses an approach similar to what we
On 01/08/2025 13:27, Richard Biener wrote:
On Thu, Jul 31, 2025 at 11:44 AM Richard Biener
wrote:
On Mon, May 19, 2025 at 6:38 PM Richard Earnshaw wrote:
It's not enough to just check that a memory operand is of the form
mem(reg); after RA we also need to validate the register being
On 27/05/2025 07:33, Christophe Lyon wrote:
> On Mon, 26 May 2025 at 18:14, Christophe Lyon
> wrote:
>>
>> Remove #pragma GCC target ("arch=armv8.2-a+bf16") and preceding
>> target and is thus useless.
> I guess this should read:
> Remove #pragma GCC target ("arch=armv8.2-a+bf16") since it matches
On 18/06/2025 21:46, Alexandre Oliva wrote:
On Jun 18, 2025, Richard Earnshaw wrote:
On 18/06/2025 10:31, Alexandre Oliva wrote:
On Jun 9, 2025, "Richard Earnshaw (lists)" wrote:
On 08/06/2025 14:15, Alexandre Oliva wrote:
VxWorks kernel mode doesn't support thumb co
On 18/06/2025 10:31, Alexandre Oliva wrote:
On Jun 9, 2025, "Richard Earnshaw (lists)" wrote:
On 08/06/2025 14:15, Alexandre Oliva wrote:
VxWorks kernel mode doesn't support thumb code, so the test fails.
Require thumb2 support.
You already have -march=armv7, so that im
On 28/05/2025 18:17, Karl Meakin wrote:
> The CB family of instructions does not support using the CS or CC
> condition codes; instead the synonyms HS and LO must be used. GCC has
> traditionally used the CS and CC names. To work around this while
> avoiding test churn, add new `j` and `J` format s
On 08/06/2025 14:15, Alexandre Oliva wrote:
>
> VxWorks kernel mode doesn't support thumb code, so the test fails.
> Require thumb2 support.
You already have -march=armv7, so that implies any thumb code will be thumb2.
So this doesn't really make sense as this is a compile-only test. Furthermo
On 20/05/2025 05:26, Alexandre Oliva wrote:
> The backport of commit 205515da82a2914d765e74ba73fd2765e1254112 to
> gcc-14 as 8b1146fe46e62f8b03bd9ddee48995794e192e82, rewriting
> gcc.target/arm/fp16-aapcs-[1234].c into check-function-bodies, requires
> the following patch for the one-character func
It's not enough to just check that a memory operand is of the form
mem(reg); after RA we also need to validate the register being used.
The safest way to do this is to call memory_operand.
PR target/120351
gcc/ChangeLog:
* config/arm/predicates.md (mem_noofs_operand): Also check
chard.
I'll commit the following to the repository:
diff --git a/MAINTAINERS b/MAINTAINERS
index b1e7fadf1b8..a3e3f25d9d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -57,7 +57,6 @@ docs, and the testsuite related to that.
aarch64 ldp/stp Alex Coplan
aarch64 port
On 11/04/2025 17:36, Christophe Lyon wrote:
> The test was designed to pass with thumb2, but code generation changed
> with the introduction of Low Overhead Loops, so the test can fail if
> one overrides the flags when running the testsuite.
>
> In addition, useless subtract / extension instructio
These registers can no-longer be allocated, so remove them from the
various tables.
gcc/ChangeLog:
* config/arm/aout.h (REGISTER_NAMES): Remove iwmmxt registers.
* config/arm/arm.h (FIRST_IWMMXT_REGNUM): Delete.
(LAST_IWMMXT_REGNUM): Delete.
(FIRST_IWMMXT_GR_REGNUM
Now that the iwmmxt extensions have been removed, clean up the
references to it in the documentation. We keep the
-mcpu/-mtune/-march references as these are still accepted by the
driver.
gcc/ChangeLog:
* doc/extend.texi: Remove the iwmmxt intrinsics.
* doc/md.texi: Remove the iw
Since we no-longer have any iwmxxt instructions, the iwmmxt-related
attributes can never be set. Consequently, the marvel-f-iwmmxt
scheduler is redundant as none of the pipes are ever used now.
gcc/ChangeLog:
* config/arm/arm.md (core_cycles): Remove iwmmxt attributes.
* config/a
Remove most of the remaining code for iWMMXT support, except for the
register allocation table entries.
gcc/ChangeLog:
* config/arm/arm-cpus.in (feature iwmmxt, feature iwmmxt2): Delete.
* config/arm/arm-protos.h (arm_output_iwmmxt_shift_immediate): Delete.
(arm_output_iw
This is the first step of removing the various builtins for iwmmxt,
removing the builtins expansion code. It leaves a lot of code
elsewhere, but we'll clean that up in subsequent patches.
I'm not sure why safe_vector_operand would unconditionally try to
expand to an iwmmxt instruction if passed (
Remove the various checks for TARGET_IWMMXT{,2} and
TARGET_REALLY_IWMMXT{,2} from the remaining machine description files.
These flags can never be true now.
gcc/ChangeLog:
* config/arm/arm.md(attr arch): Remove iwmmxt and iwmmxt2.
Remove checks based on TARGET_REALLY_IWMMXT2 from
Mostly this is just removing references to iWMMXT in comments, but also remove
some now unused iterators and attributes.
gcc/ChangeLog:
* config/arm/iterators.md (VMMX, VMMX2): Remove mode iterators.
(MMX_char): Remove mode iterator attribute.
---
gcc/config/arm/iterators.md | 20
These two tests were specific to iWMMXT, but we're about to remove
that code, so the tests are now redundant.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mmx-1.c: Removed.
* gcc.target/arm/mmx-2.c: Removed.
* gcc.target/arm/pr64208.c: Removed.
* gcc.target/arm/pr7914
Since we no-longer enable iWMMXT, these predefines are no-longer enabled
when preprocessing C. Remove them.
gcc/ChangeLog:
* config/arm/arm-c.cc (arm_cpu_builtins): Remove predefines
for __IWWMXT__, __IWMMXT2__ and __ARM_WMMX.
---
gcc/config/arm/arm-c.cc | 7 ---
1 file cha
Treat options that select iwmmxt variants as we would for xscale. We
leave the feature bits in for now, since they are still needed
elsewhere, but they are never enabled.
Also remove the remaining testsuite framework support for iwmmxt,
since this will never trigger now.
gcc/
* config/a
This patch deletes the patterns relating to iwmmxt and iwmmxt2 and
updates the relevant dependencies.
gcc/ChangeLog:
* config/arm/arm.md: Don't include iwmmxt.md.
* config/arm/t-arm (MD_INCLUDES): Remove iwmmxt*.md.
* config/arm/iwmmxt.md: Removed.
* config/arm/iwm
The iwmmxt ABI is a variant of the ABI that supported passing certain
parameters and results in iwmmxt registers. But since we no-longer
support the instructions that can read and write these registers, the
ABI variant can no-longer be used.
gcc/ChangeLog:
* config.gcc (arm, --with-abi):
it needs to access related registers. This allows GCC to continue
to work with any existing object code that uses this extension.
Richard Earnshaw (14):
arm: clarify the logic of SECONDARY_(INPUT/OUTPUT)_RELOAD_CLASS
arm: testsuite: remove iwmmxt tests
arm: treat -mcpu/arch=iwmmxt{,2} like
The flattened logic of these functions and the complexity of the
numerous clauses makes it very difficult to understand what's written
in these macros. Additionally, SECONDARY_INPUT_RELOAD_CLASS was not
laid out with the correct formatting.
Add some parenthesis and re-indent to make the logic cle
TARGET_IWMMXT, TARGET_IWMMXT2 and their _REALLY_ equivalents are never
true now, so the code using them can be simplified.
gcc/ChangeLog:
* config/arm/arm.cc (arm_option_check_internal): Remove
IWMMXT check.
(arm_options_perform_arch_sanity_checks): Likewise.
(use_
On 08/05/2025 10:21, Kyrylo Tkachov wrote:
> Hi Richard,
>
>> On 7 May 2025, at 18:15, Richard Earnshaw wrote:
>>
>>
>> The header file for the Arm implementation of mmintrin.h was changed in
>> GCC-15
>> to disable access to the intrinsics. This
For constraints there are operand modifiers and constraint qualifiers.
Operand modifiers apply to all alternatives and must appear, in
traditional syntax before the first alternative. Constraint
qualifiers, on the other hand must appear in each alternative to which
they apply.
There's no easy way
For constraints there are operand modifiers and constraint qualifiers.
Operand modifiers apply to all alternatives and must appear, in
traditional syntax before the first alternative. Constraint
qualifiers, on the other hand must appear in each alternative to which
they apply.
There's no easy way
On 07/05/2025 18:21, Richard Sandiford wrote:
> Richard Earnshaw writes:
>> On 07/05/2025 17:28, Richard Earnshaw (lists) wrote:
>>> On 07/05/2025 16:54, Richard Sandiford wrote:
>>>> Richard Earnshaw writes:
>>>>> On 07/05/2025 13:57, Richard S
On 07/05/2025 16:54, Richard Sandiford wrote:
> Richard Earnshaw writes:
>> On 07/05/2025 13:57, Richard Sandiford wrote:
>>> Kyrylo Tkachov writes:
>>>>> On 7 May 2025, at 12:27, Karl Meakin wrote:
>>>>>
>>>>> Com
On 07/05/2025 17:28, Richard Earnshaw (lists) wrote:
> On 07/05/2025 16:54, Richard Sandiford wrote:
>> Richard Earnshaw writes:
>>> On 07/05/2025 13:57, Richard Sandiford wrote:
>>>> Kyrylo Tkachov writes:
>>>>>> On 7 May 2025, at 12:27, Karl M
Since we no-longer have any iwmxxt instructions, the iwmmxt-related
attributes can never be set. Consequently, the marvel-f-iwmmxt
scheduler is redundant as none of the pipes are ever used now.
gcc/ChangeLog:
* config/arm/arm.md (core_cycles): Remove iwmmxt attributes.
* config/a
Remove most of the remaining code for iWMMXT support, except for the
register allocation table entries.
gcc/ChangeLog:
* config/arm/arm-cpus.in (feature iwmmxt, feature iwmmxt2): Delete.
* config/arm/arm-protos.h (arm_output_iwmmxt_shift_immediate): Delete.
(arm_output_iw
Remove the various checks for TARGET_IWMMXT{,2} and
TARGET_REALLY_IWMMXT{,2} from the remaining machine description files.
These flags can never be true now.
gcc/ChangeLog:
* config/arm/arm.md(attr arch): Remove iwmmxt and iwmmxt2.
Remove checks based on TARGET_REALLY_IWMMXT2 from
Since we no-longer enable iWMMXT, these predefines are no-longer enabled
when preprocessing C. Remove them.
gcc/ChangeLog:
* config/arm/arm-c.cc (arm_cpu_builtins): Remove predefines
for __IWWMXT__, __IWMMXT2__ and __ARM_WMMX.
---
gcc/config/arm/arm-c.cc | 7 ---
1 file cha
Treat options that select iwmmxt variants as we would for xscale. We
leave the feature bits in for now, since they are still needed
elsewhere, but they are never enabled.
Also remove the remaining testsuite framework support for iwmmxt,
since this will never trigger now.
gcc/
* config/a
TARGET_IWMMXT, TARGET_IWMMXT2 and their _REALLY_ equivalents are never
true now, so the code using them can be simplified.
gcc/ChangeLog:
* config/arm/arm.cc (arm_option_check_internal): Remove
IWMMXT check.
(arm_options_perform_arch_sanity_checks): Likewise.
(use_
The iwmmxt ABI is a variant of the ABI that supported passing certain
parameters and results in iwmmxt registers. But since we no-longer
support the instructions that can read and write these registers, the
ABI variant can no-longer be used.
gcc/ChangeLog:
* config.gcc (arm, --with-abi):
This patch deletes the patterns relating to iwmmxt and iwmmxt2 and
updates the relevant dependencies.
gcc/ChangeLog:
* config/arm/arm.md: Don't include iwmmxt.md.
* config/arm/t-arm (MD_INCLUDES): Remove iwmmxt*.md.
* config/arm/iwmmxt.md: Removed.
* config/arm/iwm
These registers can no-longer be allocated, so remove them from the
various tables.
gcc/ChangeLog:
* config/arm/aout.h (REGISTER_NAMES): Remove iwmmxt registers.
* config/arm/arm.h (FIRST_IWMMXT_REGNUM): Delete.
(LAST_IWMMXT_REGNUM): Delete.
(FIRST_IWMMXT_GR_REGNUM
These two tests were specific to iWMMXT, but we're about to remove
that code, so the tests are now redundant.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mmx-1.c: Removed.
* gcc.target/arm/mmx-2.c: Removed.
* gcc.target/arm/pr64208.c: Removed.
* gcc.target/arm/pr7914
Mostly this is just removing references to iWMMXT in comments, but also remove
some now unused iterators and attributes.
gcc/ChangeLog:
* config/arm/iterators.md (VMMX, VMMX2): Remove mode iterators.
(MMX_char): Remove mode iterator attribute.
---
gcc/config/arm/iterators.md | 20
for an Armv5te architecture.
Richard Earnshaw (13):
arm: clarify the logic of SECONDARY_(INPUT/OUTPUT)_RELOAD_CLASS
arm: testsuite: remove iwmmxt tests
arm: treat -mcpu/arch=iwmmxt{,2} like XScale
arm: remove iWMMX builtins support.
arm: Remove iwmmxt patterns.
arm: remove IWMMXT checks
This is the first step of removing the various builtins for iwmmxt,
removing the builtins expansion code. It leaves a lot of code
elsewhere, but we'll clean that up in subsequent patches.
I'm not sure why safe_vector_operand would unconditionally try to
expand to an iwmmxt instruction if passed (
The flattened logic of these functions and the complexity of the
numerous clauses makes it very difficult to understand what's written
in these macros. Additionally, SECONDARY_INPUT_RELOAD_CLASS was not
laid out with the correct formatting.
Add some parenthesis and re-indent to make the logic cle
On 07/05/2025 13:57, Richard Sandiford wrote:
Kyrylo Tkachov writes:
On 7 May 2025, at 12:27, Karl Meakin wrote:
Commit the test file `cmpbr.c` before rules for generating the new
instructions are added, so that the changes in codegen are more obvious
in the next commit.
I guess that’s an L
On 10/04/2025 14:55, Christophe Lyon wrote:
> All arm effective-targets using check_runtime use the "_hw" or
> "_multilib" suffix, so rename arm_v8_1_lob_ok into arm_v8_1_lob_hw for
> consistency.
>
> gcc/testsuite/ChangeLog
>
> * lib/target-supports.exp: Rename arm_v8_1_lob_ok into
>
On 06/04/2025 19:49, Christophe Lyon wrote:
The previous version of this test required arch v6+ (for sxth), and
the number of vmov depended on the float-point ABI (where softfp
needed more of them to transfer floating-point values to and from
general registers).
With this patch we require arch v
On 20/03/2025 16:15, Christophe Lyon wrote:
> These tests force dg-options because they rely on -ftree-vectorize and
> do not make use of torture options, so move them to simd/ where they
> belong.
>
> gcc/testsuite/
> *
> gcc.target/aarch64/advsimd-intrinsics/saturating_arithmetic_au
Prior to Armv6, the SMULL and UMULL instructions, which have the form
UMULL Rdlo, Rdhi, Rm, Rs
had an operand restriction such that Rdlo, Rdhi and Rm must all be
different registers. Rs, however can overlap either of the
destination registers. Add some register-tie alternatives to allow
th
On 20/03/2025 16:15, Christophe Lyon wrote:
> Remove dg-options, so that the test is executed as expected using the
> options defined by advsimd-intrinsics.exp.
> (Previously we pretend we do, but in fact all torture options are
> silently overriden with -O2)
>
> We skip it at -O0, because the tes
Besides Arm, there are three other ports that define both CCFPmode and
CCFPEmode. AArch64 and Sparc return CCFPEmode for LTGT; the other,
Visium, doesn't support LTGT at all.
AArch64 was changed in r8-5286-g8332c5ee8c5f3b, and Sparc with
r10-2926-g000a5f8d23c04c.
I suspect this issue is latent o
On Arm, running
make check-gcc RUNTESTFLAGS="dwarf2.exp=pr43190.c"
with a target list of "arm-qemu{,-mthumb}"
results in no errors. But running it with
make check-gcc RUNTESTFLAGS="{mve,dwarf2}.exp=pr43190.c"
results in unresolved tests while running the thumb variant. The pr
On Arm we have been failing to fully implement support for IEEE NaNs
in inequality comparisons because we have allowed reversing of
inequalities in a way that allows SELECT_CC_MODE to produce different
answers. For example, the reverse of GT is UNLE, but if we pass these
two RTL codes to SELECT_CC
On 01/04/2025 09:42, Kyrylo Tkachov wrote:
> Hi all,
>
> As we're starting a new month, introduce a more appropriate -mapril=
> to specify the compilation target instead.
> This helps keep GCC more up to date with the passage of time.
>
> Bootstrapped and tested on aarch64-none-linux-gnu.
>
> Si
On 31/03/2025 20:04, Christophe Lyon wrote:
> Recent syntactic fixes enabled the test, but the result was failing.
>
> It turns out it was missing a space between the register arguments in
> the scan-assembler-times directives.
>
> gcc/testsuite/ChangeLog:
>
> PR target/119556
> * gc
This is another case of a test that was both an executable test
requiring specific hardware and an assembler scan test. The
requirement for the hardware was masking some useful testing that
could be done (by scanning the assembly output) on almost all test
runs. Fixed in a similar manner to fmaxm
On 20/03/2025 16:15, Christophe Lyon wrote:
> Many tests became unsupported on aarch64 when -mcpu=unset was added to
> arm_v8_2a_fp16_neon_ok and arm_v8_2a_bf16_neon_ok effective targets,
> because this flag is only supported on arm.
>
> Since these effective targets are used on arm and aarch64, t
On 27/03/2025 14:48, Christophe Lyon wrote:
Some targets (like arm) need some flags to enable _Float16 support.
gcc/testsuite/ChangeLog:
PR target/119133
* gcc.dg/torture/pr119133.c: Add options for float16.
---
gcc/testsuite/gcc.dg/torture/pr119133.c | 1 +
1 file changed, 1
On 27/03/2025 15:37, Sam James wrote:
In r15-8956-ge90d6c2639c392, I missed one, so while it did fix a problem,
it also exposed another because the braces were now unbalanced.
There's IMO more to do here with ideally whitespace before the } when
using scan-assembler-times but let's do that later
On 26/03/2025 18:34, David Malcolm wrote:
> Found by dg-lint.
>
> gcc/testsuite/ChangeLog:
> * gcc.target/arm/cmse/cmse-17.c: Fix missing space before trailing
> "}" in dg-options.
> * gcc.target/arm/short-vfp-1.c: Likewise for dg-final; also after
> leading "{", in 5 place
On 26/03/2025 18:34, David Malcolm wrote:
> Found by dg-lint.
>
> gcc/testsuite/ChangeLog:
> * gcc.target/aarch64/atomic-inst-ldlogic.c: Add missing trailing
> " }" for 2 dg-final directives.
> * gcc.target/aarch64/saturating_arithmetic_1.c: Fix dg-do compile.
> * gcc.targe
This test has presumably been failing since vectorization was enabled
at -O2. I suspect part of the reason this wasn't picked up sooner is
that the test is a hybrid execution/scan-assembler test and the
execution part requires appropriate hardware.
The problem is that we are vectorizing an expans
These tests need access to the MRC instruction, but that isn't part of
of the Thumb1 ISA. So skip the tests when this isn't the case.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mtp_1.c: Require arm32.
* gcc.target/arm/mtp_2.c: Likewise.
* gcc.target/arm/mtp_3.c: Likewise.
The ftest-*.c tests for Arm check certain ACLE mandated macros to ensure
they are correctly defined based on the selected architecture. ACLE
states that the macro should be defined if the operation exists in
the hardware, but it doesn't have to exist in the current ISA because
and interworking cal
As the primary LTO file in this test, it cannot use dg-options. Move
the flags from there to dg-lto-options.
gcc/testsuite/ChangeLog:
* gcc.target/arm/lto/pr96939_0.c (dg-options): Delete. Move the
options from here ...
(dg-lto-options): ... to here.
---
gcc/testsuite/
Similar to r15-4930-gd56d2f3102ada3, update the branch operations when not
using CBN?Z for inverting the direction of the branch operations.
gcc/testsuite/ChangeLog:
* gcc.target/arm/vect-early-break-cbranch.c: Allow BEQ as well as BNE.
---
.../gcc.target/arm/vect-early-break-cbranch.c
This test has missing prototypes. To avoid disturbing the test, use gnu17.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr65647.c (dg-options): Add -std=gnu17.
---
gcc/testsuite/gcc.target/arm/pr65647.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.t
These tests have been looking for a very specific instruction sequence
which has the tendency to be fairly unstable as a result. But what is
more interesting is that the the tests must not contain instructions
that can't be used for unaligned data, and whether or not the copy is
executed correctly
On 21/03/2025 17:30, Christophe Lyon wrote:
> On Fri, 21 Mar 2025 at 16:51, Richard Earnshaw (lists)
> wrote:
>>
>> On 21/03/2025 15:15, Christophe Lyon wrote:
>>> On Fri, 21 Mar 2025 at 15:25, Richard Earnshaw (lists)
>>> wrote:
>>>>
>>>&
On 24/03/2025 14:52, Christophe Lyon wrote:
> On Mon, 24 Mar 2025 at 15:13, Richard Earnshaw (lists)
> wrote:
>>
>> On 21/03/2025 17:30, Christophe Lyon wrote:
>>> On Fri, 21 Mar 2025 at 16:51, Richard Earnshaw (lists)
>>> wrote:
>>>>
>>>&
The scan-assembler-not pattern in this test was too broad and matched
the 'unaligned' from the .file directive from the file name. Tighten it
to require a leading comment character.
gcc/testsuite:
* gcc.target/arm/unaligned-memcpy-4.c: Tighten scan-assembler-not
pattern.
---
gcc
On 20/03/2025 16:15, Christophe Lyon wrote:
> Remove dg-options, so that the test is executed as expected using the
> options defined by advsimd-intrinsics.exp.
>
> gcc/testsuite/
> * gcc.target/aarch64/advsimd-intrinsics/vmla_float_not_fused.c:
> Remove dg-options.
> * gcc
On 21/03/2025 15:15, Christophe Lyon wrote:
> On Fri, 21 Mar 2025 at 15:25, Richard Earnshaw (lists)
> wrote:
>>
>> On 21/03/2025 14:05, Christophe Lyon wrote:
>>> On Fri, 21 Mar 2025 at 11:18, Richard Earnshaw (lists)
>>> wrote:
>>>>
On 20/03/2025 16:15, Christophe Lyon wrote:
> Like a previous patch, replace "" with -mfpu=auto to match the
> intended effect of -march=armv8.2-a+fp16.
>
> No visible change because the effect is masked by other effective
> targets used in the tests, done for consistency.
>
> gcc/testsuite
On 21/03/2025 14:05, Christophe Lyon wrote:
> On Fri, 21 Mar 2025 at 11:18, Richard Earnshaw (lists)
> wrote:
>>
>> On 20/03/2025 16:15, Christophe Lyon wrote:
>>> Depending on if/how the testing flags are overridden, the first value
>>> we try("") m
This test is designed to check that if one of the operands is
aligned (but the other isn't) we expand to a sensible sequence and
bypass most of the overhead of doing a memcpy. But on targets without
unaligned accessess, we still end up calling memcpy. It's then a
lottery as to whether the prologu
On 20/03/2025 16:15, Christophe Lyon wrote:
> Like previous patches, fix the use of -mcpu=unset and -mfpu=auto in
> several effective target shared between aarch64 and arm.
>
> aarch64 does not support these flags, so we use them only on arm.
>
> Replace "" with -mfpu=auto in the first flags we t
On 20/03/2025 16:15, Christophe Lyon wrote:
> Many tests became unsupported on aarch64 when -mcpu=unset was added to
> arm_v8_2a_fp16_neon_ok and arm_v8_2a_bf16_neon_ok effective targets,
> because this flag is only supported on arm.
>
> Since these effective targets are used on arm and aarch64, t
On 20/03/2025 16:15, Christophe Lyon wrote:
> r14-7202-gc8ec3e1327cb1e added vld1xN and vst1xN intrinsics and some
> tests on arm, but didn't enable some existing tests.
>
> Since these tests are shared with aarch64, this patch removes the
> 'dg-skip-if "unimplemented" { arm*-*-* }' directives and
On 20/03/2025 16:15, Christophe Lyon wrote:
> Depending on if/how the testing flags are overridden, the first value
> we try("") might not do what we want.
>
> For instance, if the whole testsuite is executed with
> (A) -mthumb -march=armv7-m -mtune=cortex-m3 -mfloat-abi=softfp
>
> bf16_neon_ok i
On 20/03/2025 16:15, Christophe Lyon wrote:
> Tests under advsimd-intrinsics are controlled by
> advsimd-intrinsics.exp which computes the adequate dg-do-what
> depending on the actual target, it should not be redefined in the
> tests, except when the action can never be 'run'.
>
> This currently
On 20/03/2025 16:15, Christophe Lyon wrote:
> This was probably a typo / oversight.
>
> gcc/testsuite/
> * lib/target-supports.exp
> (check_effective_target_arm_v8_1_lob_ok): Remove duplicate
> -mcpu=unset.
> ---
> gcc/testsuite/lib/target-supports.exp | 2 +-
> 1 file cha
If expand_binop_directly fails to add a REG_EQUAL note it tries to
unwind and restart. But it can unwind too far if expand_binop changed
some of the operands before calling it. We don't need to unwind that
far anyway since we should end up taking exactly the same route next
time, just without a t
On 13/03/2025 08:22, Christophe Lyon wrote:
> Since we have vcmp and vcmpe instructions (vcmpe raises an "Invalid
> Operation" exception in presence of a NaN operand), we need to tell
> the compiler it is not safe to reverse comparisons of floating-point
> arguments.
>
> On armv8-m.main+dsp+fp (co
This test has been failing since gcc-6. The test was always very
fragile anyway since it relied on an auto-inc being created and then
split by the subreg2 (later the subreg3) pass. But the code to get
precisely these conditions was very long-winded and unlikely to be
immune to other changes in th
Subregs that only change the mode of an operand (ie don't change the
size) should be safe for the VPR register. If we don't permit them
we may end up with some redundant copy instructions.
gcc:
PR target/115439
* config/arm/predicates.md (vpr_register_operand): Allow type-punning
On 11/03/2025 13:46, Torbjorn SVENSSON wrote:
Is it okay to backport below patch and r15-7890-gb7f5d911480 to
releases/gcc-14?
Yes, sure.
R.
Kind regards,
Torbjörn
On 2025-03-11 12:06, Richard Earnshaw wrote:
GCC will complain if the -mcpu flag specifies a different architecture
to that
1 - 100 of 1319 matches
Mail list logo
