On 10/09/2025 10:54, Christophe Lyon wrote:
> If the results include several configurations (schedule of
> variations), do not report summary lines as duplicates. Indeed with
> several configurations, it's likely that the results contain the same
>
># of expected passesX
>
>
Insufficient validation of the operands in vec_set__internal
means that the optimizers can transform the exanded code into
something that is invalid. We then emit code based on the incorrect
RTL assuming that it is still valid. A valid pattern can only have a
single bit set in the immediate opera
On arm, overriding -march can lead to warnings if the testsuite
options try to pass -mcpu. Avoid these by ensuring the -mcpu is unset
before adding the architecture.
Also, improve the compatibility of asm-hard-reg-error-3.c for
hard-float environment by allowing FP instructions in the
architectur
On 01/09/2025 14:02, Christophe Lyon wrote:
> Test "names" (the string after 'PASS:' or 'FAIL:' etc... is expected
> to be unique, otherwise this will confuse comparison scripts.
>
> This patch displays the lists of non-unique test names in the 'before'
> and in the 'now' results.
>
> contrib/Ch
On 01/09/2025 10:59, Christophe Lyon wrote:
> Test "names" (the string after 'PASS:' or 'FAIL:' etc... is expected
> to be unique, otherwise this will confuse comparison scripts.
>
> This patch displays the lists of non-unique test names in the 'before'
> and in the 'now' results.
>
> contrib/Ch
On 29/08/2025 14:57, Christophe Lyon wrote:
On Fri, 29 Aug 2025 at 15:50, Christophe Lyon
wrote:
On Fri, 29 Aug 2025 at 15:35, Richard Earnshaw wrote:
On 27/08/2025 15:45, Christophe Lyon wrote:
The thumb2_asrl, thumb2_lsll and thumb2_lsrl patterns were incorrecly
using (match_dup 0) for
On 27/08/2025 15:45, Christophe Lyon wrote:
The thumb2_asrl, thumb2_lsll and thumb2_lsrl patterns were incorrecly
using (match_dup 0) for the first argument of the shift operator.
This patch replaces that with (match_operand:DI 1
arm_general_register_operandarm_general_register_operand "0") and
On 18/08/2025 18:32, Christophe Lyon wrote:
On Mon, 18 Aug 2025 at 19:24, 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 imp
On 10/08/2025 12:51, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-15?
For releases/gcc-15, I would also want to cherry-pick r16-562-g20c25919132 that
converts
the test to use function body instead of three scan-assembler.
Changes since v1:
- Removed the acceptance of LDR as it's only
The compiler is getting too smart! But this test is really intended
to test that we generate BICS instead of BIC+CMP, so make the test use
something that we can't subsequently fold away into a bit minipulation
of a store-flag value.
I've also added a couple of extra tests, so we now cover both th
Sandiford
> Bernd Schmidt
> Ian Lance Taylor
> Jim Wilson
> @@ -56,7 +56,6 @@ docs, and the testsuite related to that.
>
> aarch64 ldp/stp
On 19/06/2025 14:25, Alexandre Oliva wrote:
> On Jun 19, 2025, Alexandre Oliva wrote:
>
>> Or maybe the requirements for this testcase should be stated as
>> arm_arch_v7? I'd have to add arm_arch_v7 to
>> check_effective_target_arm_arch_FUNC_ok et al, if there aren't reasons
>> why it's not ther
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
1 - 100 of 1331 matches
Mail list logo
