On Fri, 8 Aug 2025 at 16:58, Richard Earnshaw wrote:
>
> 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
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 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,
> >
In commit r15-4417-g71c7b446b98aa5, I made -werror mandatory when
building libgcc for aarch64.
While it achieved its goal (make us fix problems unnoticed so far),
there has a been a lot of debate because it couldn't be disabled
easily.
This patch adds support for --enable-werror/--disable-werror
Ping?
Le lun. 7 juil. 2025, 19:07, Christophe Lyon a
écrit :
> On Mon, 7 Jul 2025 at 15:47, Torbjorn SVENSSON
> wrote:
> >
> >
> >
> > On 2025-07-03 15:02, Christophe Lyon wrote:
> > > ping^2 ?
> >
> > Looks fine to me, but as you know, my app
ping?
On Sat, 5 Jul 2025 at 00: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.
>
&g
ping?
On Thu, 10 Jul 2025 at 16: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
ping?
On Sat, 5 Jul 2025 at 00:01, 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
ping?
On Sat, 5 Jul 2025 at 00:01, 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
> t
Hi Torbjörn,
On Fri, 11 Jul 2025 at 10:47, 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 vec
Thanks for the update.
Like in your other email, there are still formatting issues.
Here is the version I applied manually and used in CI.
Christophe
On Thu, 10 Jul 2025 at 01:46, Matt Parks wrote:
>
> This patch fixes PR117366:
> arm thumb1 epilogue size optimizer violates -ffixed-r4.
>
> gcc
Hi,
Thanks for the update.
There are still some formatting problems, some of which might be
caused by your mailer.
I manually applied the patch and manually triggered CI, the new test
passed without regression.
Here is the version I tested, let's wait for Richard's feedback.
Christophe
On Thu
RE_MEM (we need to remove -slim for
that). The tests enable an FPU via -march so that the test passes
whether the testing harness forces -mfloat-abi or not.
2025-07-08 Christophe Lyon
PR target/120977
gcc/
* config/arm/arm.md (call): Move unspec parameter t
Hi,
Thanks for your patch, I think the same comments apply as the ones I
just sent for your other patch
(https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689121.html)
Christophe
On Thu, 26 Jun 2025 at 01:35, Matt Parks wrote:
>
> Fixing issue with thumb1 code generation clobbering register.
Hi,
Thanks for the patch, the code change looks sensible to me, but you'll
have to wait for Richard (in cc) as he is the maintainer.
However I have a few comments below:
On Thu, 26 Jun 2025 at 00:57, Matt Parks wrote:
>
> Trying again, hopefully formatted correctly this time, and now including a
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-g5163cf2ae14. Since
> I'm currently looking into gcc-14 release, and made the patch in that
> scope, I r
On Tue, 8 Jul 2025 at 17:17, 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 r
On Mon, 7 Jul 2025 at 15:47, Torbjorn SVENSSON
wrote:
>
>
>
> On 2025-07-03 15:02, Christophe Lyon wrote:
> > ping^2 ?
>
> Looks fine to me, but as you know, my approval does not count.
>
Thanks for confirming I didn't miss anything from your intentions.
Christ
ping?
On Tue, 27 May 2025 at 08: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:
>
ping?
On Mon, 26 May 2025 at 18: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
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 do on aarch64, but only
partially since Neon i
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 typos / oversights.
gcc/testsuite/ChangeLog:
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 -march or -mcpu which
supports Thumb-1 only: in su
ping^2 ?
On Wed, 18 Jun 2025 at 12:11, Christophe Lyon
wrote:
>
> ping?
>
> On Mon, 26 May 2025 at 17:26, Christophe Lyon
> wrote:
> >
> > On Mon, 26 May 2025 at 17:14, Christophe Lyon
> > wrote:
> > >
> > > Commit r15-7152-g57b706d141
ping?
On Mon, 26 May 2025 at 17:26, Christophe Lyon
wrote:
>
> On Mon, 26 May 2025 at 17:14, Christophe Lyon
> wrote:
> >
> > Commit r15-7152-g57b706d141b87c removed
> > /* { dg-do run { target*-*-linux* *-*-gnu* *-*-uclinux* } } */
> >
> > from these
We often see timeouts when running these tests on simulator, and
Joern's patch apply cleanly (and fix the problem).
OK to backport to gcc-14?
Thanks,
Christophe
Joern Rennecke (2):
Reduce iteration counts for gcc.dg/vect/tsvc tests.
Fix PR testsuite/116271, gcc.dg/vect/tsvc/vect-tsvc-s176.c
From: Joern Rennecke
testsuite/
* gcc.dg/vect/tsvc/tsvc.h (iterations): Allow to override,
default to 10.
(get_expected_result): Add values for iterations counts
10, 256 and 3200.
(run): Add code to output values for new iterations counts.
* gcc.dg/
From: Joern Rennecke
gcc/testsuite:
PR testsuite/116271
* gcc.dg/vect/tsvc/vect-tsvc-s176.c [TRUNCATE_TEST]: Make sure
that m stays the same as the loop bound of the middle loop.
* gcc.dg/vect/tsvc/tsvc.h (get_expected_result) [TRUNCATE_TEST]:
Adjust expec
Hi!
On Mon, 2 Jun 2025 at 20:53, Andre Vehreschild wrote:
>
> Hi Thomas,
>
> thanks for the ok. Unfortunately does the patch regress in gomp (test case
> gomp/pr104382 when I am not mistaken ; the one with the lone 'save'
> statement). This was reported by the regression testing host at first
Some tests have 'dg-do link' but currently require 'tls' which is a
compile-only check.
In some configurations of arm-none-eabi, the 'tls' effective-target
can be successful although these tests fail to link with
undefined reference to `__aeabi_read_tp'
This patch as a new tls_link effective targ
A few arm effective-targets call check_effective_target_arm32 even
though they would force an -march=XXX flag which support Arm and/or
Thumb-2, thus making the arm32 check useless. This has an impact when
the toolchain is configured with a default -march or -mcpu which
supports Thumb-1 only: in su
On Mon, 26 May 2025 at 18:35, 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.
>
&g
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 the preceding
pragma G
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 do on aarch64, but only
partially since Neon i
Remove #pragma GCC target ("arch=armv8.2-a+bf16") and preceding
target and is thus useless.
gcc/ChangeLog:
* config/arm/arm_neon.h: Remove useless push/pop pragmas.
---
gcc/config/arm/arm_neon.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/gcc/config/arm/arm_neon.h b/gcc/confi
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: #error "NEON intrinsics not available with the
s
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 typos.
gcc/testsuite/ChangeLog:
* lib/t
On Mon, 26 May 2025 at 17:14, Christophe Lyon
wrote:
>
> Commit r15-7152-g57b706d141b87c removed
> /* { dg-do run { target*-*-linux* *-*-gnu* *-*-uclinux* } } */
>
> from these tests, turning them into 'compile' only tests, even when
> they could be executed.
>
>
Commit r15-7152-g57b706d141b87c removed
/* { dg-do run { target*-*-linux* *-*-gnu* *-*-uclinux* } } */
from these tests, turning them into 'compile' only tests, even when
they could be executed.
This patch adds
/* { dg-do run } */
which is OK since the tests are correctly skipped if needed thank
,,
On Mon, 26 May 2025 at 12:54, Andrew Pinski (QUIC)
wrote:
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: Monday, May 26, 2025 3:09 AM
> > To: Andrew Pinski (QUIC)
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH]
Hi Andrew,
On Sun, 17 Nov 2024 at 22:49, Andrew Pinski wrote:
>
> Instead of doing a dg-run with a specific target check for linux.
> Use signal as the effective-target since this requires the use
> of ALARM signal to do the testing.
> Also use check_vect in the main and renames main to main1 to
On Wed, 21 May 2025 at 10:56, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > Many tests became unsupported on aarch64 when -mcpu=unset was added to
> > several arm_* effective targets, because this flag is only supported
> > on arm.
> >
> > Since the
Many tests became unsupported on aarch64 when -mcpu=unset was added to
several arm_* effective targets, because this flag is only supported
on arm.
Since these effective targets are used on arm and aarch64, the patch
adds -mcpu=unset on arm only, and restores "" on aarch64.
This re-enables lots o
On Tue, 20 May 2025 at 06:27, 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-ch
On Tue, 20 May 2025 at 06:30, 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
Ping?
Le ven. 11 avr. 2025, 18:36, Christophe Lyon a
écrit :
> 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, u
Ping?
Le jeu. 17 avr. 2025, 11:21, Christophe Lyon a
écrit :
> Since this test is a 'dg-do run', it requires tls_runtime rather than
> just tls.
>
> This makes the test UNSUPPORTED on targets such as arm-non-eabi,
> instead of FAIL/UNRESOLVED because __aeabi_read_tp is
Ping?
Le jeu. 17 avr. 2025, 11:21, Christophe Lyon a
écrit :
> This test is 'dg-do compile', so require tls instead of tls_runtime.
>
> This enables it on targets such as arm-none-eabi configured with
> --enable-threads=no.
>
> gcc/testsuite/ChangeLog:
>
>
Hi!
On Tue, 22 Apr 2025 at 13:55, Thomas Schwinge wrote:
>
> Hi!
>
> On 2025-04-17T18:15:50+, ci_notify--- via Gcc-regression
> wrote:
> > Our automatic CI has detected problems related to your patch(es). Please
> > find some details below.
> >
> > In bootstrap_check master-arm-check_boots
This test is 'dg-do compile', so require tls instead of tls_runtime.
This enables it on targets such as arm-none-eabi configured with
--enable-threads=no.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/constinit16.C: Require tls.
---
gcc/testsuite/g++.dg/cpp2a/constinit16.C | 2 +-
1 file chan
Since this test is a 'dg-do run', it requires tls_runtime rather than
just tls.
This makes the test UNSUPPORTED on targets such as arm-non-eabi,
instead of FAIL/UNRESOLVED because __aeabi_read_tp is not provided
(e.g. when GCC is configured with --enable-threads=no.
gcc/testsuite/ChangeLog:
On Wed, 16 Apr 2025 at 16:14, Hans-Peter Nilsson wrote:
>
> > From: Christophe Lyon
> > Date: Wed, 16 Apr 2025 14:41:17 +0200
>
> > ping?
>
> Since you directed it at me and CC:ed the list; in case that
> was deliberate: I can only repeat "still ok"
ping?
On Thu, 10 Apr 2025 at 15:48, Hans-Peter Nilsson wrote:
>
> > From: Christophe Lyon
> > Date: Thu, 10 Apr 2025 15:38:48 +0200
>
> > On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson wrote:
> > >
> > > > From: Christophe Lyon
> > > &
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 instructions require -O2 to
remove them (-O is not sufficient),
Hi!
On Thu, 10 Apr 2025 at 19:13, Richard Earnshaw (lists)
wrote:
>
> 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
On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson wrote:
>
> > From: Christophe Lyon
> > Date: Thu, 10 Apr 2025 15:21:23 +0200
>
> Not sure why I'm CC:ed on this one, not being a maintainer
> of the testsuite or targets where gcov tests are exercised,
Because yo
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
arm_v8_1_lob_hw.
* gcc.target/arm/lob1.c: Likew
ping?
On Tue, 1 Apr 2025 at 22:37, Christophe Lyon wrote:
>
> After commit r15-8947-g8ed2d5d219e999, which added new tests using
> gcov, the CI noticed failures because it was calling 'gcov' instead of
> $target-gcov.
>
> This is because the CI scripts override G
On Sun, 6 Apr 2025 at 14:39, Paul Richard Thomas
wrote:
>
> Hi All,
>
> As far as I can tell, the attached patch fixes the problems with the reduce
> intrinsic. I would be grateful to the reporters if they would confirm that
> this is the case.
>
> The key to the fix appears in reduce_3.f90, whi
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 v7-a, vfp FPU and -mfloat-abi=hard, we
also use
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 tested optimizations does not take
place at this level.
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.target/aarch64/advsimd-intrinsics/vmls_float_not_
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 relies on the
advsimd-intrinsics.exp driver to define
On Fri, 21 Mar 2025 at 11:39, Richard Biener wrote:
>
> On Fri, 21 Mar 2025, Richard Earnshaw wrote:
>
> > 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 d
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("") might not do what we want.
> >
> > For instance, if the
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
* gcc.target/arm/short-vfp-1.c: Add missing spaces.
---
gcc/t
On Fri, 21 Mar 2025 at 16: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:
> &
Since r15-7878-ge1c49f413c8, these tests appear as XPASS on aarch64,
so we can remove the xfails introduced by r12-102-gf31ddad8ac8f11.
gcc/testsuite/ChangeLog:
* gcc.dg/guality/pr90074.c: Remove xfail for aarch64.
* gcc.dg/guality/pr90716.c: Likewise.
---
gcc/testsuite/gcc.dg/gu
After commit r15-8947-g8ed2d5d219e999, which added new tests using
gcov, the CI noticed failures because it was calling 'gcov' instead of
$target-gcov.
This is because the CI scripts override GXX_UNDER_TEST, but still run
the testsuite in-tree, and gcc-transform-out-of-tree only depends on
TESTING
Le dim. 30 mars 2025, 22:10, Sam James a écrit :
> Jakub Jelinek writes:
>
> > Hi!
> >
> > r15-8956 changed in the test:
> > -/* { dg-final { scan-assembler-times "ldclr\t" 16} */
> > +/* { dg-final { scan-assembler-times "ldclr\t" 16 } */
> > which made it even worse than before, when the direc
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 insertion(+)
diff --git a/gcc/testsuite/gcc.dg
On Mon, 24 Mar 2025 at 16:13, 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 Fr
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:
> >>
> >> On 21/03/2025 15:15, Christophe Lyon wrote:
> >>> On Fr
On Fri, 21 Mar 2025 at 18: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:
> &
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 is first compiled with
(A) (B)
where B = -mcpu=unset -march
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 21/03/2025 14:05, Christophe Lyon wrote:
> >>> On Fr
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:
> >>> Depe
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, the patch
adds -mcpu=unset on arm only, and restores ""
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 try on arm to make
sure the intended FPU effect of -march
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/
* lib/target-supports.exp
(check_effec
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_autovect.inc:
Move to gcc.target/aarch64/simd/.
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 makes no difference, but it would when we remove
dg-skip
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 changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/
ally extends testing coverage, especially on aarch64
where many tests had inadvertently become unsupported.
Christophe Lyon (10):
testsuite: arm: remove duplicate -mcpu=unset in arm_v8_1_lob_ok
testsuite: aarch64: arm: move saturating_arithmetic_autovect tests to
simd/
testsuite: aarc
On Wed, 12 Mar 2025 at 08:05, Richard Biener wrote:
>
> On Tue, Mar 11, 2025 at 5:58 PM Christophe Lyon
> wrote:
> >
> > In https://gcc.gnu.org/contribute.html#patches we ask to use [PR]
> > without the Bugzilla component identifier and with no space between
&
On Tue, 11 Mar 2025 at 17:21, 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 replaces the
> 'dg-s
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 (cortex-m33):
PASS: gcc.dg/torture/builtin-iseqsig-1.c
at -
On Mon, 10 Mar 2025 at 13:00, Richard Earnshaw (lists)
wrote:
>
> 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
In https://gcc.gnu.org/contribute.html#patches we ask to use [PR]
without the Bugzilla component identifier and with no space between
'PR' and the number, but git_check_commit.py accepts all forms. The
patch enforces what we document.
Note that this would reject a few of the recent commits.
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 replaces the
'dg-skip-if "unimplemented" { arm*-*-* }' directives with:
dg-require-effective-target arm_neon_ok { target a
Hi!
On Fri, 7 Mar 2025 at 23:57, Sandra Loosemore wrote:
>
> gcc/ChangeLog
> PR sanitizer/56682
> * doc/invoke.texi (Instrumentation Options): Document that -g
> is useful with -fsanitize=thread and -fsanitize=address.
> Also mention -fno-omit-frame-pointer per th
On Thu, 6 Mar 2025 at 11:03, Christophe Lyon wrote:
>
> On Wed, 5 Mar 2025 at 12:59, Richard Earnshaw wrote:
> >
> > The header file arm_neon.h provides the Advanced SIMD intrinsics that
> > are available on armv7 or later A & R profile cores. However, they
> >
On Wed, 5 Mar 2025 at 12:59, Richard Earnshaw wrote:
>
> 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
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/-fPIC/-fPIE and -mno-pic-data-is-text-relative -mlong-ca
On Mon, 3 Mar 2025 at 12:29, Richard Sandiford
wrote:
>
> Tamar Christina writes:
> >> -Original Message-
> >> From: Richard Sandiford
> >> Sent: Monday, March 3, 2025 10:12 AM
> >> To: Tamar Christina
> >> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> >> ; ktkac...@gcc.gnu.org
>
Hi,
On Thu, 20 Feb 2025 at 15:18, 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 in
On Tue, 18 Feb 2025 at 13:49, Richard Earnshaw (lists)
wrote:
>
> 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&#x
As discussed in the PR, removing the inner 'fix:HF/SD/DF' fixes the
problem, like other targets do.
gcc/ChangeLog:
PR rtl-optimization/117712
* config/arm/arm.md (fix_trunchfsi2): Remove inner fix:HF.
(fix_trunchfdi2): Likewise.
(fix_truncsfsi2): Remove inner fix:S
Almost a copy/paste from the recent aarch64 version of this patch,
this one is a bit more intrusive because it also introduces
arm_general_gimple_fold_builtin.
With this patch,
gcc.target/arm/aes_xor_combine.c scan-assembler-not veor
passes again.
gcc/ChangeLog:
PR target/114522
On Sun, 2 Feb 2025 at 21:18, Thiago Jung Bauermann
wrote:
>
> Since commit r15-491-gc290e6a0b7a9de this failure happens on on
> armv8l-linux-gnueabihf and arm-eabi:
>
> Running gcc:gcc.target/arm/simd/simd.exp ...
> gcc.target/arm/simd/mve-vabs.c: memmove found 0 times
> FAIL: gcc.target/arm/simd/
1 - 100 of 1253 matches
Mail list logo
