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
On Wed, 11 Dec 2024 at 17:54, Richard Earnshaw (lists)
wrote:
>
> On 07/11/2024 09:18, Christophe Lyon wrote:
> > This patch series re-implements the store_scatter and load_gather
> > intrinsincs using the new framework, similarly to previous series.
> >
> >
not 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 target/114801
gcc/
* config/arm/arm-mve-builtins.cc
(function_expander::add_input_operand): Handle
This patch is largely a copy/paste from the aarch64 SVE counterpart,
and adds support for tuples to the MVE intrinsics framework.
Introduce function_resolver::infer_tuple_type which will be used to
resolve overloaded vst2q and vst4q function names in a later patch.
Fix access to acle_vector_types
Now that tuples are properly supported, we can update the store shape, to expect
"t0" instead of "v0" as last argument.
gcc/ChangeLog:
* config/arm/arm-mve-builtins-shapes.cc (struct store_def): Add
support for tuples.
---
gcc/config/arm/arm-mve-builtins-shapes.cc | 4 ++--
1 fil
ix.
The introduction of all these new modes instead of just OImode and
XImode makes a few parts more verbose though.
This patch series applies on top of the previous one "Rework
store_scatter and load_gather intrinsics".
Christophe Lyon (4):
arm: [MVE intrinsics] add modes for tuples
ar
Implement vst2q, vst4q, vld2q and vld4q using the new MVE builtins
framework.
Since MVE uses different tuple modes than Neon, we need to use
VALID_MVE_STRUCT_MODE because VALID_NEON_STRUCT_MODE is no longer a
super-set of it, for instance in output_move_neon and
arm_print_operand_address.
In arm_
Add V2x and V4x modes, like we do on aarch64 for Advanced SIMD
q-registers.
gcc/ChangeLog:
* config/arm/arm-modes.def (MVE_STRUCT_MODES): New.
---
gcc/config/arm/arm-modes.def | 22 ++
1 file changed, 22 insertions(+)
diff --git a/gcc/config/arm/arm-modes.def b/gcc/c
On Fri, 6 Dec 2024 at 12:41, Richard Earnshaw (lists)
wrote:
>
> On 04/12/2024 20:56, Christophe Lyon wrote:
> > On Wed, 4 Dec 2024 at 12:39, Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 25/11/2024 20:08, Christophe Lyon wrote:
> >>> In this P
Like dlstp-compile-asm-1.c, this test would fail if GCC is configured
with non-default options, such as -mtune=cortex-a9.
Force -mtune=cortex-m55 to avoid this unexpected issue.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mve/dlstp-int8x16.c: Add -mtune=cortex-m55
---
gcc/testsuite/gcc.ta
This test would fail if GCC is configured with non-default options,
such as -mtune=cortex-a9.
This 'unexpected' scheduling makes the DLSTP optimization generate
subslr, #16
bhi .L4
lctp
pop {r4, r5, pc}
.L4:
sub ip, ip, #16
b
i
Le mer. 4 déc. 2024, 21:56, Christophe Lyon a
écrit :
> On Wed, 4 Dec 2024 at 12:39, Richard Earnshaw (lists)
> wrote:
> >
> > On 25/11/2024 20:08, Christophe Lyon wrote:
> > > In this PR, we have to handle a case where MVE predicates are supplied
> > &
On Wed, 4 Dec 2024 at 12:39, Richard Earnshaw (lists)
wrote:
>
> On 25/11/2024 20:08, 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
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 Mon, 2 Dec 2024 at 12:44, Richard Earnshaw (lists)
wrote:
>
> On 02/12/2024 11:21, 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 wa
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 Mon, 2 Dec 2024 at 10:45, Tejas Belagod wrote:
>
> On 11/30/24 3:30 AM, Christophe Lyon wrote:
> > Hi!
> >
> > On Fri, 29 Nov 2024 at 05:00, Tejas Belagod wrote:
> >>
> >> This patch changes the TYPE_INDIVISBLE flag to 0 to enable SVE ACLE types
Hi!
On Fri, 29 Nov 2024 at 05:00, Tejas Belagod wrote:
>
> This patch changes the TYPE_INDIVISBLE flag to 0 to enable SVE ACLE types to
> be
> treated as GNU vectors and have the same semantics with operations that are
> defined on GNU vectors.
>
> gcc/ChangeLog:
>
> * config/aarch64/aar
On 11/29/24 15:15, Andre Vieira wrote:
Address a problem we were having where we were missing on detecting uses of
vctp_vpr_generated in the analysis for 'arm_attempt_dlstp_transform' because
the use was inside a SUBREG and rtx_equal_p does not catch that. Using
reg_overlap_mentioned_p is mu
On 11/29/24 15:14, Andre Vieira wrote:
After the changes to the vctp intrinsic codegen changed slightly, where we now
unfortunately seem to be generating unneeded moves and extends of the mask.
These are however not incorrect and we don't have a fix for the unneeded
codegen right now, so chan
Hi,
On Mon, 25 Nov 2024 at 21:08, 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 0xc for a 4-bit boolean predicate). To avoid the ICE,
> fix th
FTR this patch is superseded by Andre's patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670378.html
On Thu, 28 Nov 2024 at 11:12, Christophe Lyon
wrote:
>
> After the recent c23, GCC complains because the testcase calls f()
> with a parameter whereas the prot
On 11/29/24 11:30, Andre Vieira wrote:
This patch series does not really need to be a patch series but just makes it
easier to send it all and has one common goal which is to clean up the DLSTP
implementation new to GCC 16 after some codegen changes. The first two patches
clean-up some testcas
On 11/29/24 11:30, Andre Vieira wrote:
Address a problem we were having where we were missing on detecting uses of
vctp_vpr_generated in the analysis for 'arm_attempt_dlstp_transform' because
the use was inside a SUBREG and rtx_equal_p does not catch that. Using
reg_overlap_mentioned_p is mu
On 11/29/24 11:30, Andre Vieira wrote:
This fixes a testism introduced by the warning produced with the -std=c23
default. The testcase is a reduced piece of code meant to trigger an ICE, so
there's little value in trying to change the code itself.
gcc/testsuite/ChangeLog:
* gcc.tar
On 11/29/24 11:30, Andre Vieira wrote:
After the changes to the vctp intrinsic codegen changed slightly, where we now
unfortunately seem to be generating unneeded moves and extends of the mask.
These are however not incorrect and we don't have a fix for the unneeded
codegen right now, so chan
1 - 100 of 1204 matches
Mail list logo
