/pr116479.c: New test.
On 23/04/2025 16:51, Jakub Jelinek wrote:
On Wed, Apr 23, 2025 at 04:46:04PM +0100, Andre Vieira (lists) wrote:
On 23/04/2025 16:22, Jakub Jelinek wrote:
On Wed, Apr 23, 2025 at 03:57:58PM +0100, Andre Vieira (lists) wrote:
+++ b/gcc/testsuite/gcc.target/aarch64/pr116479.c
On 23/04/2025 16:22, Jakub Jelinek wrote:
On Wed, Apr 23, 2025 at 03:57:58PM +0100, Andre Vieira (lists) wrote:
+++ b/gcc/testsuite/gcc.target/aarch64/pr116479.c
@@ -0,0 +1,20 @@
+/* PR 116479 */
+/* { dg-do run } */
+/* { dg-additional-options "-O -funroll-loops -finline-stringops -fm
In the commit titled 'doloop: Add support for predicated vectorized
loops' the doloop_condition_get function was changed to accept loops
with decrements larger than 1. This patch rejects such loops for
modulo-sched.
I've put the test for this in the aarch64 testsuite, but I just realized
eve
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 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
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
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
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 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
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:
>>>>
>>>&
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
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
Here is the latest version of the patch, I wasn't sure whether Richard's
'LGTM with...' was meant as a conditional OK and together with the
changes suggested by Andrew I thought I'd ask again, OK for trunk?
As per the AArch64 ISA FEAT_SME does not require FEAT_SVE2. However, we
don't support
Thanks for the suggestions.
On 14/03/2025 21:43, Andrew Carlotti wrote:
On Thu, Mar 13, 2025 at 05:10:07PM +, Andre Vieira (lists) wrote:
Apologies for the delay, had been waiting on some other relevant patches to
go in to make sure we didn't break any valid existing behaviours. It s
On 14/03/2025 09:59, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
diff --git a/gcc/testsuite/gcc.target/aarch64/no-sve-with-sme-3.c
b/gcc/testsuite/gcc.target/aarch64/no-sve-with-sme-3.c
new file mode 100644
index
00
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
Apologies for the delay, had been waiting on some other relevant patches
to go in to make sure we didn't break any valid existing behaviours. It
should all be working properly now. I think I've also addressed all your
comments. Most notable change is that it now uses the 'sorry' mechanism.
Bo
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
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
>
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:
> Ok for trunk and releases/gcc-14?
>
>
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 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_vector_label to avoid the zero
>>> use count on minipool_ve
On 13/02/2025 21:43, H.J. Lu wrote:
> Increment LABEL_NUSES when using minipool_vector_label to avoid the zero
> use count on minipool_vector_label.
>
> PR target/118866
> * config/arm/arm.cc (arm_reorg): Increment LABEL_NUSES when
> using minipool_vector_label.
>
Whilst this patch isn't wrong p
On 12/02/2025 11:01, Christophe Lyon wrote:
> 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
On 04/02/2025 03:20, Sebastian Huber wrote:
> - Am 4. Feb 2025 um 4:15 schrieb Sebastian Huber
> sebastian.hu...@embedded-brains.de:
>
>> Enable use of Armv8-M instruction set.
>>
>> Account for CVE-2021-35465 mitigation [PR102035]. The
>> -mfix-cmse-cve-2021-35465 enabled by default, if -mc
On 27/01/2025 18:07, Ian Lance Taylor wrote:
> Richard Earnshaw writes:
>
>> Older versions of the Arm architecture lack support for __sync
>> operations directly in hardware and require calls into appropriate
>> operating-system hooks. But such hooks obviously don't exist in a
>> freestanding e
On 19/01/2025 16:34, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> Using -std=c17 avoids excess errors like:
> .../thumb-bitfld1.c:15:1: warning: old-style function definition
> [-Wold-style-definition]
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/thumb-bitfld1.c: Use -std=c17
On 24/01/2025 17:01, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> gcc/testsuite/ChangeLog:
>
> PR testsuite/116448
> * gcc.target/arm/vfp-1.c: Use -Os -fno-math-errno.
>
> Signed-off-by: Torbjörn SVENSSON
> ---
> gcc/testsuite/gcc.target/arm/vfp-1.c | 2
On 21/01/2025 21:58, Jason Merrill wrote:
On 1/15/25 7:36 PM, yxj-github-437 wrote:
On Fri, Jan 03, 2025 at 05:18:55PM +, xxx wrote:
From: yxj-github-437 <2457369...@qq.com>
This patch attempts to fix an error when build module std. The
reason for the
error is __builrin_va_list (aka struc
On 07/01/2025 20:16, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> Since armv8-m.base uses thumb1 that does not suport sigcall/tailcall,
> a pattern is needed that uses PUSH/BL/POP sequence instead of a single
> B instruction to reuse an already existing function in the
On 22/12/2024 15:35, Torbjorn SVENSSON wrote:
>
>
> On 2024-12-19 12:48, Richard Earnshaw (lists) wrote:
>> On 18/12/2024 16:24, Torbjörn SVENSSON wrote:
>>> Changes since v1:
>>>
>>> - Updated the commit message to reflect the changes (including the s
On 09/01/2025 21:42, Torbjörn SVENSSON wrote:
> Changes since v1:
>
> - Added dg-add-options arm_arch_v5te_thumb
> - Added -std=c17 to dg-options.
> - Removed -march=armv5te -mfloat-abi=soft -mthumb from dg-options
> - Updated the commit message to reflect the new changes
>
> Note: This changes f
On 09/01/2025 14:50, Christophe Lyon wrote:
> 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 pat
On 20/12/2024 22: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
> TI, OI and XI modes, which appear for
On 27/12/2024 17:01, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> This change will enforce that the expected instructions are generated
> per function rather than allowing some other function to use the
> expected instructions.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/armv
On 27/12/2024 08:32, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> The implementation of the functions in the test case expects there to be
> a few arguments to the helper functions, but the prototype does not have
> any arguments at all. Align these to avoid these errors:
>
> .../pr59858.
On 22/12/2024 15:27, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> When the test was initially created, -fcommon was the default, but in
> commit r10-4867-g6271dd984d7 the default value changed to -fno-common.
> This change made the test start failing. To counter the ove
On 08/01/2025 21:47, Thiago Jung Bauermann wrote:
> "Richard Earnshaw (lists)" writes:
>
>> On 27/12/2024 21:47, Thiago Jung Bauermann wrote:
>>> In 32-bit Arm assembly, the @ character is the start of a comment so
>>> the section type needs to use the %
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 force_lowpart_subreg does not exist in gcc-14: the patch
> replaces it with the equivalent:
>
> -x = force
On 08/01/2025 18:54, Christophe Lyon wrote:
> 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/Change
On 27/12/2024 21:47, Thiago Jung Bauermann wrote:
> In 32-bit Arm assembly, the @ character is the start of a comment so
> the section type needs to use the % character instead.
>
> configure.ac attempts to account for this difference by doing a second
> try when checking the assembler for section
On 08/01/2025 13:37, Christophe Lyon wrote:
> 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
On 08/01/2025 13:56, Tamar Christina wrote:
>> -Original Message-
>> From: Richard Earnshaw (lists)
>> Sent: Wednesday, January 8, 2025 1:18 PM
>> To: Christophe Lyon ; gcc-patches@gcc.gnu.org;
>> Richard Sandiford ; Tamar Christina
>> ; Andre Simoes
On 19/12/2024 12:17, Christophe Lyon wrote:
> 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 co
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 or directory
> because they are actually compiled with
> -mfloat-abi=softfp -mfpu=auto -mcpu=unse
On 19/12/2024 12:17, Christophe Lyon wrote:
> 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_co
On 19/12/2024 12:17, Christophe Lyon wrote:
> 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/comple
On 19/12/2024 16:45, Christophe Lyon wrote:
> 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 doe
On 18/12/2024 16:24, Torbjörn SVENSSON wrote:
> Changes since v1:
>
> - Updated the commit message to reflect the changes (including the subject).
> - Replaced the POP/BEQ checks with chesk for {cmp,mov,orr,and}{eq,ne}.
> - Removed the size check
>
>
> Ok for trunk and releases/gcc-14?
> Should
On 18/12/2024 19:57, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> Update test case to align with used function in C++26.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/abi/arm_rtti1.C: Check for expected symbol in C++26.
>
> Signed-off-by: Torbjörn SVENSSON
OK.
R.
> ---
> gcc/tests
On 18/12/2024 18:45, Torbjörn SVENSSON wrote:
> Changes since v1:
>
> - Split tests into two parts. One part for doing asm checkes. Another part
> for doing run test as these require hardware to be available.
> - Changed existing tests to be "compile" instead of "run".
>
> Changes since v2:
>
On 17/12/2024 21:01, Torbjörn SVENSSON wrote:
> Regtested for arm-none-eabi (Cortex-M0/M23/M33/M55/M85).
>
> Ok for trunk?
>
> --
>
> Without the escape of the tab, newline and semicolon, the generated
> assembler output will not match the expected assmbler in the test cases.
>
> Fixes Linaro C
On 05/11/2024 07:55, Torbjorn SVENSSON wrote:
>
>
> On 2024-11-04 15:41, Richard Earnshaw wrote:
>> On 01/11/2024 18:40, Richard Earnshaw (lists) wrote:
>>> On 24/10/2024 09:50, Torbjörn SVENSSON wrote:
>>>> Ok for trunk and releases/gcc-14?
>>>&
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:
>>> On Sun, 10 Nov 2024 at 17:44, Torbjörn SVENSSON
>>> wrote:
Ok for trunk and releases/gcc-14?
--
When the
On 17/12/2024 14:32, Torbjorn SVENSSON wrote:
>
>
> On 2024-12-17 12:06, Richard Earnshaw (lists) wrote:
>> On 17/12/2024 07:04, Torbjörn SVENSSON wrote:
>>> Ok for trunk?
>>>
>>> --
>>>
>>> Fixes Linaro CI reported regression on r15-6
On 10/11/2024 19:25, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> Test fails for Cortex-M0 with:
>
> .../pr81812.C:6:8: error: generic thunk code fails for method 'virtual void
> ChildNode::_ZTv0_n12_NK9ChildNode5errorEz(...) const' which uses '...'
>
> According to
On 17/12/2024 07:04, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
> https://linaro.atlassian.net/browse/GNU-1463.
>
> gcc/testsuite/ChangeLog:
>
> * lib/target-supports.exp: Added corresponding -mtune= option
>
On 17/12/2024 08:01, Gerald Pfeifer wrote:
> On Fri, 20 Sep 2024, Tobias Burnus wrote:
>> This is supposed to document that GCC now supports offloading,
>> e.g., from an ARM CPU to a Nvidia GPU (i.e. Grace<->Hopper)
>> or, e.g., x86-64 to RISC-V. → https://gcc.gnu.org/PR96265
>> and https://gcc.gnu
On 13/12/2024 14:29, Christophe Lyon wrote:
> 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, wher
On 06/12/2024 16:09, Christophe Lyon wrote:
> 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-
On 12/12/2024 13:47, Torbjorn SVENSSON wrote:
On 2024-12-12 12:02, Richard Earnshaw (lists) wrote:
On 10/11/2024 10:02, Torbjörn SVENSSON wrote:
Ok for trunk, releases/gcc-12, releases/gcc-13 and releases/gcc-14?
--
In version 6-2017-q1-update of the "GNU Arm Embedded Toolchain&q
On 12/12/2024 13:36, Torbjorn SVENSSON wrote:
On 2024-12-12 12:26, Richard Earnshaw (lists) wrote:
On 10/11/2024 13:38, Torbjörn SVENSSON wrote:
Hi Richard,
I'm not sure if I'm doing something wrong here, or if it was an
oversight
when doing the update in r12-8108-g62082d278
On 14/11/2024 10:42, Christophe Lyon wrote:
V2DF is not supported by MVE, so remove it from the only iterator
which contains it.
gcc/ChangeLog:
* config/arm/iterators.md (MVE_vecs): Remove V2DF.
---
gcc/config/arm/iterators.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
On 14/11/2024 10:41, Christophe Lyon wrote:
Remove floating-point condition from mve_vec_extract_sext_internal and
mve_vec_extract_zext_internal, since the MVE_2 iterator does not
include any FP mode.
gcc/ChangeLog:
* config/arm/mve.md (mve_vec_extract_sext_internal): Fix
condit
On 10/11/2024 13:38, Torbjörn SVENSSON wrote:
Hi Richard,
I'm not sure if I'm doing something wrong here, or if it was an oversight
when doing the update in r12-8108-g62082d278d1.
Anyway, the commit message suggest that it's only the constant that is of
interrest, so I updated the test to only c
On 10/11/2024 10:02, Torbjörn SVENSSON wrote:
Ok for trunk, releases/gcc-12, releases/gcc-13 and releases/gcc-14?
--
In version 6-2017-q1-update of the "GNU Arm Embedded Toolchain" build,
there are 2 pop instructions. In version 7-2018-q2-update, the next
version that still have a binary build
On 09/12/2024 15:05, Christophe Lyon wrote:
Changes v1->v2:
- Keep MAX_TUPLE_SIZE=0 and update accesses to acle_vector_types
accordingly.
- implement arm_array_mode in patch 4/4 instead of 2/4 to avoid
temporary regressions when running the testsuite at patch 2/4 (helps
future bisects)
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.
A few points worth mentioning:
- unlike other intrinsics, these ones have the predicate after the
mode in their nam
On 11/12/2024 09:54, Tamar Christina wrote:
-Original Message-
From: Richard Sandiford
Sent: Wednesday, December 11, 2024 9:50 AM
To: Tamar Christina
Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
; ktkac...@gcc.gnu.org
Subject: Re: [PATCH 1/2]AArch64: Add CMP+CSEL and CMP+CSET for
On 03/12/2024 10:41, Claudio Bantaloukas wrote:
On 12/3/2024 10:24 AM, Kyrylo Tkachov wrote:
Hi Claudio,
On 2 Dec 2024, at 19:14, Claudio Bantaloukas
wrote:
The previous version of the patch was based on the mistaken
assumption that
features in /proc/cpuinfo had matching names to the fe
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 0xc for a 4-bit boolean predicate). To avoid the ICE,
fix the constant (any non-zero value is conver
On 06/12/2024 18:14, Christophe Lyon wrote:
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 PR, we have to handle a
On 09/12/2024 08:16, Richard Biener wrote:
On Fri, 6 Dec 2024, Richard Earnshaw wrote:
The vcond{,u} expander paterns have been declared as obsolete. Remove
them from the Arm backend.
OK (not sure if you were expecting approval from me ;)), the patterns
are no longer exercised anywhere.
My
On 06/12/2024 16:09, Christophe Lyon wrote:
> 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-
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 PR, we have to handle a case where MVE predicates are supplied
>>> as a const_int, wher
On 06/12/2024 10:02, Christophe Lyon wrote:
> 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}
On 28/05/2024 10:31, Gerald Pfeifer wrote:
> On Mon, 10 Jul 2023, Kyrylo Tkachov via Gcc-patches wrote:
>> I know the GCC source is inconsistent on this but the proper branding
>> these days is "ARM" -> "Arm" and "ARMv8.1-M" -> "Armv8.1-M".
>
> Arm, Red Hat, and SUSE - those three are spelt incor
I was just looking back through some old emails and saw that this was never
reviewed.
On 26/04/2024 18:37, Andrew Pinski wrote:
> On many cores, the mov instruction is "free" so the sequence:
> cmp w0, #0
> csetw0, ne
> add w0, w0, 42
> is more expensive than j
On 29/11/2024 06:02, Arvin Zhong wrote:
> Hi GCC reviewers,
>
> The star-mc1 CPU is an Armv8-m Mainline CPU supporting ARM CDE feature.
> The attached is the patch to support adding CDE options for -mcpu=star-mc1.
> The patch has been built and tested on the GCC upstream with arm-none-eabi.
>
> I
On 02/12/2024 21: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 warnings about 'pure attribute on function returning
> void' when we declare the various load intrinsics because their
>
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> Update test case to use -mcpu=unset/-march=unset feature introduced in
> r15-3606-g7d6c6a0d15c.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/lto/pr96939_0.c: Use effective-target
> arm_arch_v8a.
> * gcc.target/arm/lto/pr96939_
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> The test case gcc.target/arm/its.c was created together with restriction
> of IT blocks for Cortex-M7. As the test case fails on all tunes that
> does not match Cortex-M7, explicitly test it for Cortex-M7. To have some
> additional faith that GCC does
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> Update test cases to use -mcpu=unset/-march=unset feature introduced in
> r15-3606-g7d6c6a0d15c.
>
> gcc/testsuite/ChangeLog:
> * gcc.dg/pr41574.c: Added option "-mcpu=unset".
> * gcc.dg/pr59418.c: Likewise.
> * lib/target-supports.
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> Update test cases to use -mcpu=unset/-march=unset feature introduced in
> r15-3606-g7d6c6a0d15c.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/bfloat16_scalar_1_1.c: Use effective-target
> arm_arch_v8_2a_bf16_hard.
> * gcc.targ
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> Update test cases to use -mcpu=unset/-march=unset feature introduced in
> r15-3606-g7d6c6a0d15c.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/other/pr56184.C: Use effective-target
> arm_arch_v7a_neon_thumb.
> * g++.dg/other/pr59985.C:
On 21/11/2024 17:23, Torbjörn SVENSSON wrote:
> I'm not sure how to verify that adding the parameter won't destroy the test.
> I've tried to repoduce the ICE on old Arm builds of arm-none-eabi, but none of
> them ICE. I suppose it should be safe to add the parameter as the PR talks
> about the lite
1 - 100 of 1235 matches
Mail list logo
