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
GCC will complain if the -mcpu flag specifies a different architecture
to that specified in -march, but if the floating-point ABI is "soft",
then differences in the floating-point architecture features are
ignored.
However, the arm_libc_fp_abi checks whether we change the FP ABI by
adding -mfloat-
On 16/01/2025 14:20, Christophe Lyon wrote:
> When compiling c-c++-common/vector-compare-3.c with
> -march=armv8.1-m.main+mve+fp.dp -mfloat-abi=hard -mfpu=auto
> (which enables MVE), we fail to match vcond_mask because operand 3 has
> s_register_operand as predicate for a MVE_VPRED mode, but we try
On 07/03/2025 21:12, Jonathan Wakely wrote:
> It's very unlikely that anybody is still using the old remotes/$user Git
> repo setup and still needs this script to be able to migrate it to the
> remotes/users/$user structure. Simplify the script by removing those
> parts.
>
> This fixes an error th
With -mfpu set to auto, an architecture specification that lacks
floating-point, but has -mfloat-abi=softfp will cause a misleading
error. Specifically, if we have
gcc -c test.c -mfloat-abi=softfp -march=armv7-a -mfpu=auto
where test.c contains #include
then we get a misleading error:
test.c:
On 04/03/2025 11:01, Christophe Lyon wrote:
> Commit r9-4307-g89d7557202d25a forgot to accept a fixed PIC register
> when extending the assert in require_pic_register.
>
> arm_pic_register can be set explicitly by the user
> (e.g. -mpic-register=r9) or implicitly as the default value with
> -fpic/
On 20/02/2025 14:09, Hannes Braun wrote:
> vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting
> pointers to unsigned integers. These parameters should be pointers to
> signed integers.
>
> gcc/ChangeLog:
>
> * config/arm/arm_neon.h (vld1q_s8_x3): Use int8_t instead of
>
The header file arm_neon.h provides the Advanced SIMD intrinsics that
are available on armv7 or later A & R profile cores. However, they
are not compatible with M-profile and we also need to ensure that the
FP instructions are enabled (with -mfloat-abi=softfp/hard). That
leads to some complicated
On 04/03/2025 14:49, Torbjorn SVENSSON wrote:
>
>
> On 2025-03-03 18:00, Richard Earnshaw wrote:
>> On 28/02/2025 16:18, Richard Earnshaw wrote:
>>> On 28/02/2025 16:12, Richard Earnshaw wrote:
>>>> On 08/11/2024 18:47, Torbjörn SVENSSON wrote:
&g
The code in gcc.target/unsigned-extend-1.c really should not need an
unsigned extension operations when the optimizers are used. For Arm
and thumb2 that is indeed the case, but for thumb1 code it gets more
complicated as there are too many instructions for combine to look at.
For thumb1 we end up
On 28/02/2025 16:18, Richard Earnshaw wrote:
> On 28/02/2025 16:12, Richard Earnshaw wrote:
>> On 08/11/2024 18:47, Torbjörn SVENSSON wrote:
>>> Ok for trunk and releases/gcc-14?
>>>
>>> --
>>>
>>> A long time ago, this test forced -march
On 28/02/2025 16:12, Richard Earnshaw wrote:
On 08/11/2024 18:47, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
A long time ago, this test forced -march=armv6.
With -marm, the generated assembler is:
foo:
sub r0, r0, #48
cmp r0, #9
movhi
On 08/11/2024 18:47, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
A long time ago, this test forced -march=armv6.
With -marm, the generated assembler is:
foo:
sub r0, r0, #48
cmp r0, #9
movhi r0, #0
movls r0, #1
bx
On 08/11/2024 17:44, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr68674.c: Use effective-target arm_arch_v7a
and arm_libc_fp_abi.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.target/arm/pr68674.c | 7 +++
On 17/12/2024 15:04, Richard Earnshaw (lists) wrote:
> On 15/11/2024 10:15, Christophe Lyon wrote:
>> On Thu, 14 Nov 2024 at 18:33, Torbjorn SVENSSON
>> wrote:
>>>
>>>
>>>
>>> On 2024-11-14 16:53, Christophe Lyon wrote:
>>>&
This test uses incremental linking, but that can generate warnings if
the LTO step contains a mix of LTO and non-LTO object files (this can
happen when there's a testglue file that is normally included during
linking).
We don't care about the testglue, though, so just tell the LTO
optimizer to gen
On 26/02/2025 15:59, Jakub Jelinek wrote:
> Hi!
>
> The linaro CI found my PR119002 patch broke bootstrap on arm.
> Seems the problem is that it has incorrect REVERSE_CONDITION macro
> definition.
> All other target's REVERSE_CONDITION definitions and the default one
> just use the macro's argumen
On 18/02/2025 08:37, Christophe Lyon wrote:
> As discussed in the PR, removing the inner 'fix:HF/SD/DF' fixes the
> problem, like other targets do.
>
The double-'fix' idiom was introduced in
https://gcc.gnu.org/pipermail/gcc-patches/2003-March/098380.html to address
target/5985. Certainly at t
On 17/02/2025 13:54, Richard Earnshaw (lists) wrote:
> On 17/02/2025 12:42, H.J. Lu wrote:
>> On Mon, Feb 17, 2025 at 7:08 PM Richard Earnshaw (lists)
>> wrote:
>>>
>>> On 13/02/2025 21:43, H.J. Lu wrote:
>>>> Increment LABEL_NUSES when using minipool_
1 - 100 of 1301 matches
Mail list logo
