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/
Enabling 'fp' on v8.1-m.main (either via +fp, +fp.dp or +mve.dp)
enables support for fp16 types (and registers _Float16 in C++).
As the g++.dg/cpp23/ext-floating13.C testcase shows, this pulls
typeinfo for _Float16 at link time, but a toolchain built using
t-rmprofile currently relies on v8-m.main
On Mon, 27 Jan 2025 at 13:30, Torbjorn SVENSSON
wrote:
>
> Hi Christophe,
>
> On 2025-01-27 13:07, Christophe Lyon wrote:
> > Hi Torbjorn,
> >
> > On Fri, 24 Jan 2025 at 18:45, Torbjorn SVENSSON
> > wrote:
> >>
> >> Another ping... :)
> &g
4-11-14 17:16, Torbjorn SVENSSON wrote:
> >>
> >>
> >> On 2024-11-14 16:32, Christophe Lyon wrote:
> >>> On Fri, 8 Nov 2024 at 19:49, Torbjörn SVENSSON
> >>> wrote:
> >>>>
> >>>> Ok for trunk and releases/gcc-14?
>
If the target does not support floating-point, we register FP vector
types as 'void' (see register_vector_type).
The leads to warnings about 'pure attribute on function returning
void' when we declare the various load intrinsics because their
call_properties say CP_READ_MEMORY (thus giving them th
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 to
match:
(insn 26 25 27 2 (set (reg:V4SI 137)
On Tue, 14 Jan 2025 at 14:11, Christophe Lyon
wrote:
>
> If the target does not support floating-point, we register FP vector
> types as 'void' (see register_vector_type).
>
> The leads to warnings about 'pure attribute on function returning
> void' when
If the target does not support floating-point, we register FP vector
types as 'void' (see register_vector_type).
The leads to warnings about 'pure attribute on function returning
void' when we declare the various load intrinsics because their
call_properties say CP_READ_MEMORY (thus giving them th
On 1/13/25 15:05, Torbjorn SVENSSON wrote:
Hi Richard and Robin,
It looks like this patch introduced a regression with MVE (Cortex-M55
and Cortex-M85).
If I try to build testsuite/c-c++-common/vector-compare-3.c (there are
other test cases that fail with a similar ICE):
arm-none-eabi-gc
The previous fix only worked for C, for C++ we need to add more
information to the underlying type so that
finish_class_member_access_expr accepts it.
We use the same logic as in aarch64's register_tuple_type for AdvSIMD
tuples.
This patch makes gcc.target/arm/mve/intrinsics/pr118332.c pass in C+
On Thu, 9 Jan 2025 at 12:25, Richard Earnshaw (lists)
wrote:
>
> On 09/01/2025 08:58, Christophe Lyon wrote:
> > OK for gcc-14?
> >
> > This backport is a cherry pick of commit
> > 2089009210a1774c37e527ead8bbcaaa1a7a9d2d, with a small change needed
> > because
x27;1'), see the
section on MVE intrinsics in the Arm ACLE specification.
Since force_lowpart_subreg cannot handle const_int (because they have VOID
mode),
use gen_lowpart on them, force_lowpart_subreg otherwise.
2024-11-20 Christophe Lyon
Jakub Jelinek
PR tar
The previous fix only worked for C, for C++ we need to add more
information to the underlying type so that
finish_class_member_access_expr accepts it.
This patch makes gcc.target/arm/mve/intrinsics/pr118332.c pass in C++
mode.
gcc/ChangeLog:
PR target/118332
* config/arm/arm-mve-
On Wed, 8 Jan 2025 at 14:17, Richard Earnshaw (lists)
wrote:
>
> On 19/12/2024 12:17, Christophe Lyon wrote:
> > Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail
> > to compile on arm-linux-gnueabihf with
> > fatal error: gnu/stubs-soft.h: No such file
A recent commit mistakenly changed the field name for tuples from
'val' to '__val', but unlike SVE this name is mandated by ACLE.
The patch simply switches back the name to 'val'.
PR target/118332
gcc/ChangeLog:
* config/arm/arm-mve-builtins.cc (wrap_type_in_struct): Use 'val'
ping?
On Fri, 20 Dec 2024 at 23:53, Christophe Lyon
wrote:
>
> Commit r15-6389-g670df03e5294a3 only partially fixed support for moves
> of large modes: despite the introduction of V2x* and V4x* modes in
> r15-6245-g4f4e13dd235b to support MVE tuples, we still need to support
>
On Mon, 23 Dec 2024 at 05:58, Andrew Pinski wrote:
>
> On Fri, Dec 13, 2024 at 6:31 AM Christophe Lyon
> wrote:
> >
> > On Tue, 10 Dec 2024 at 13:14, Richard Earnshaw (lists)
> > wrote:
> > >
> > > On 09/12/2024 21:11, Christophe Lyon wrote:
>
Commit r15-6389-g670df03e5294a3 only partially fixed support for moves
of large modes: despite the introduction of V2x* and V4x* modes in
r15-6245-g4f4e13dd235b to support MVE tuples, we still need to support
TI, OI and XI modes, which appear for instance in gcc.dg/pr100887.c.
The problem was noti
On Thu, 19 Dec 2024 at 13:17, Christophe Lyon
wrote:
>
> Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail
> to compile on arm-linux-gnueabihf with
> fatal error: gnu/stubs-soft.h: No such file or directory
> because they are actually compiled with
> -mfloa
Commit r15-6245-g4f4e13dd235b introduced new modes for MVE tuples, but
missed adding support for them in a few places.
Adding them to the list in arm_attr_length_move_neon is not sufficient
since we later face another ICE where the compiler does not know how
to split move of such data.
The patch
Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail
to compile on arm-linux-gnueabihf with
fatal error: gnu/stubs-soft.h: No such file or directory
because they are actually compiled with
-mfloat-abi=softfp -mfpu=auto -mcpu=unset -march=armv8.3-a+fp16
Fix this by including stdint.
The test uses floats, not fp16 so it should use arm_v8_3a_complex_neon
instead of arm_v8_3a_fp16_complex_neon.
This makes it PASS on arm-linux-gnueabihf instead of being UNRESOLVED.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-float.c: Use
ar
These two testcases have twice the same dg-add-options
arm_v8_3a_complex_neon, the patch removes one of them.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/complex/complex-operations-run.c: Remove duplicate
dg-add-options arm_v8_3a_complex_neon.
* gcc.dg/vect/complex/fast-math-bb
The vect testsuite adds -mfpu=neon before the arm_v8_3a_complex_neon
flags via check_vect_support_and_set_flags, so before this change
testcases are compiled with -mfpu=neon (and no -march/-mfloat-abi
flag) with an arm-linux-gnueabihf toolchain configured using
--with-float=hard --with-fpu=vfpv3-d1
On Tue, 10 Dec 2024 at 13:14, Richard Earnshaw (lists)
wrote:
>
> On 09/12/2024 21:11, Christophe Lyon wrote:
> > In this PR, we have to handle a case where MVE predicates are supplied
> > as a const_int, where individual predicates have illegal boolean
> > values (such as
1 - 100 of 1229 matches
Mail list logo
