This test has presumably been failing since vectorization was enabled
at -O2. I suspect part of the reason this wasn't picked up sooner is
that the test is a hybrid execution/scan-assembler test and the
execution part requires appropriate hardware.
The problem is that we are vectorizing an expans
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
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 match vcond_mask because operand
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 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
> > are not compatible with M-profile
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
On 04/03/2025 11:01, Christophe Lyon wrote:
> Commit r9-4307-g89d7557202d25a forgot to accept a fixed PIC register
> when extending the assert in require_pic_register.
>
> arm_pic_register can be set explicitly by the user
> (e.g. -mpic-register=r9) or implicitly as the default value with
> -fpic/
On 20/02/2025 14:09, Hannes Braun wrote:
> vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting
> pointers to unsigned integers. These parameters should be pointers to
> signed integers.
>
> gcc/ChangeLog:
>
> * config/arm/arm_neon.h (vld1q_s8_x3): Use int8_t instead of
>
The header file arm_neon.h provides the Advanced SIMD intrinsics that
are available on armv7 or later A & R profile cores. However, they
are not compatible with M-profile and we also need to ensure that the
FP instructions are enabled (with -mfloat-abi=softfp/hard). That
leads to some complicated
Hi GCC team,
This patch introduces inline definitions for the __fma and __fmaf
functions in the ARM ACLE headers for both aarch64 and arm targets. The
new implementations use the built-in functions (__builtin_fma and
__builtin_fmaf) to ensure proper inlining and adherence to the ARM ACLE
requireme
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
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 arguments, while arm.h definition uses the MODE
argument but us
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
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
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
uint16_t.
(vld1q_s16_x3): Use int16_t
> Well, this adopts the same approach as the fix for PR 117525 (same
> problem, but on hppa).
> In that PR there's also a mention of a similar problem on Sparc, and
> Konstantinos says he is working on a middle-end fix (see comment #9 in
> PR117712).
The problem clearly comes from the middle-end
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' idiom was introduced in
> https://gcc.gnu.org/pipermai
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
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
On 17/02/2025 13:54, Richard Earnshaw (lists) wrote:
> On 17/02/2025 12:42, H.J. Lu wrote:
>> On Mon, Feb 17, 2025 at 7:08 PM Richard Earnshaw (lists)
>> wrote:
>>>
>>> On 13/02/2025 21:43, H.J. Lu wrote:
Increment LABEL_NUSES when using minipool_vector_label to avoid the zero
use count
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_vector_label.
>>>
>>> PR target/118866
>>> * conf
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_vector_label.
> >
> > PR target/118866
> > * config/arm/arm.cc (arm_reorg): Increment LABEL
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
From: "H.J. Lu"
Date: Fri, 14 Feb 2025 05:25:47 +0800
Subject: [PATCH] arm: Increment LABEL_NUSES when using minipool_vector_label
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
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
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
Christophe Lyon writes:
> 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 foun
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/
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/mve-vabs.c scan-assembler-times memmove 3
In PR PR target/116010, Andre
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 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
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 environment.
>
> Consquently, it is incorrect to assum
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 environment.
Consquently, it is incorrect to assume during configure that such
functions
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 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 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
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-
Christophe Lyon writes:
> 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.
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
> TI, OI and XI modes
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 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
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
On 2024-12-18 14:59, Richard Earnshaw (lists) wrote:
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 assm
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
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 CI reported regression on r15-6166-gb7e11b499922 in
https://linaro.
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-
Hi All,
The recent commits for MVE on Saturday have broken armhf bootstrap due to a
-Werror false positive:
inlined from 'virtual rtx_def*
{anonymous}::vstrq_scatter_base_impl::expand(arm_mve::function_expander&)
const' at /gcc/config/arm/arm-mve-builtins-base.cc:352:17:
./genrtl.h:38:16: e
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 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 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.
Richard.
> gcc/ChangeLog:
>
> PR targe
The vcond{,u} expander paterns have been declared as obsolete. Remove
them from the Arm backend.
gcc/ChangeLog:
PR target/114189
* config/arm/arm-protos.h (arm_expand_vcond): Delete prototype.
* config/arm/arm.cc (arm_expand_vcond): Delete function.
* config/arm/v
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-
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
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}
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
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 Wed, 2024-12-04 at 11:22 +, Richard Earnshaw (lists) wrote:
> On 26/11/2024 15:51, David Malcolm wrote:
> > OK for trunk?
>
> OK
>
> > (caveat: I haven't done a full test on this patch)
>
> Linaro's CI has, it's clean.
Thanks; pushed as r15-5922-ga0ac8fa55a4749.
On 26/11/2024 15:51, David Malcolm wrote:
> OK for trunk?
OK
> (caveat: I haven't done a full test on this patch)
Linaro's CI has, it's clean.
R.
>
> gcc/ChangeLog:
> PR translation/90160
> * config/arm/arm.cc (arm_option_check_internal): Use quotes in
> messages that refer
On 03/12/2024 16:09, Wilco Dijkstra wrote:
The register indexed variants of LDRD have complex register overlap constraints
which makes them hard to use without using output_move_double (which can't be
used for atomics as it doesn't guarantee to emit atomic LDRD/STRD when
required).
Add a new pr
The register indexed variants of LDRD have complex register overlap constraints
which makes them hard to use without using output_move_double (which can't be
used for atomics as it doesn't guarantee to emit atomic LDRD/STRD when
required).
Add a new predicate and constraint for plain LDRD/STRD wi
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 warnings about 'pure attribute on function retu
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 warnings about 'pure attribute on function returning
> void' when we declare the various load intrinsics because their
>
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
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 prototype has none.
>
>
Hi Christophe,
On 28/11/2024 17:00, Christophe Lyon wrote:
Hi Andre,
Thanks, the patch LGTM except a minor nit:
/* Using a VPR that gets re-generated within the loop. */
-void test10 (int32_t *a, int32_t *b, int32_t *c, int n)
+void test10a (int32_t *a, int32_t *b, int32_t *c, int n)
[...]
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.
Is it OK for trunk?
Thanks.
Best Regards,
Arvin Zhong
Hi Andre,
On Thu, 28 Nov 2024 at 17:37, Andre Vieira
wrote:
>
> Hi,
>
> This rejects any loops where any predicated instruction comes before the vctp
> that generates the loop predicate. Even though this is not a requirement for
> dlstp transformation we have found potential issues where you can
Hi,
This rejects any loops where any predicated instruction comes before the vctp
that generates the loop predicate. Even though this is not a requirement for
dlstp transformation we have found potential issues where you can end up with a
wrong transformation, so it is safer to reject such loops.
On Thu, 28 Nov 2024 at 15:13, Andre Vieira (lists)
wrote:
>
> Hi Christophe,
>
> On 28/11/2024 10:22, Christophe Lyon wrote:
> > The VCTP instruction creates a Vector Tail Predicate in VPR.P0, based
> > on the input value, but also constrained by a VPT block (if present),
> > or if used within a D
Hi Christophe,
On 28/11/2024 10:22, Christophe Lyon wrote:
The VCTP instruction creates a Vector Tail Predicate in VPR.P0, based
on the input value, but also constrained by a VPT block (if present),
or if used within a DLSTP/LETP loop.
Therefore we need to inform the compiler that this intrinsi
The VCTP instruction creates a Vector Tail Predicate in VPR.P0, based
on the input value, but also constrained by a VPT block (if present),
or if used within a DLSTP/LETP loop.
Therefore we need to inform the compiler that this intrinsic reads the
FPCXT register, otherwise it could make incorrect
After the recent c23, GCC complains because the testcase calls f()
with a parameter whereas the prototype has none.
gcc/testsuite/ChangeLog
* gcc.target/arm/mve/dlstp-loop-form.c: Fix f() prototype.
---
gcc/testsuite/gcc.target/arm/mve/dlstp-loop-form.c | 2 +-
1 file changed, 1 i
OK for trunk? (caveat: I haven't done a full test on this patch)
gcc/ChangeLog:
PR translation/90160
* config/arm/arm.cc (arm_option_check_internal): Use quotes in
messages that refer to command-line options. Tweak wording.
Signed-off-by: David Malcolm
---
gcc/config/a
Hi,
Looks like single_pred ICEs if the basic-block does not have a single
predecessor rather than return NULL, which was what this snippet of code
relied on.
This feels like borderline obvious to me as a fix, but I thought I'd get
it checked by one more person.
Call 'single_pred_p' before 's
On Tue, 19 Nov 2024 at 15:00, Andre Vieira (lists)
wrote:
>
> Hi,
>
> Looks like single_pred ICEs if the basic-block does not have a single
> predecessor rather than return NULL, which was what this snippet of code
> relied on.
> This feels like borderline obvious to me as a fix, but I thought I'd
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(-)
diff --git a/gcc/config/arm/iterators.md b/gcc/con
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
condition.
(mve_vec_extract_zext_internal):
Hi,
On Fri, 1 Nov 2024 at 22:10, Torbjörn SVENSSON
wrote:
>
> There is one more problem, that this patch does not address, and that is
> that there are warnings like below, but I do not know what's causing them.
>
> .../gcc/testsuite/gcc.target/arm/pr117408-1.c:8:9: warning: 'pure' attribute
>
There is one more problem, that this patch does not address, and that is
that there are warnings like below, but I do not know what's causing them.
.../gcc/testsuite/gcc.target/arm/pr117408-1.c:8:9: warning: 'pure' attribute on
function returning 'void' [-Wattributes]
.../gcc/testsuite/gcc.target
After the re-implementation of MVE vld/vst intrinsics, a few builtins
qualifiers became useless.
This patch removes them to restore bootstrap (otherwise the build
fails because of 'defined but not used' errors.
gcc/ChangeLog:
* config/arm/arm-builtins.cc (STRS_QUALIFIERS): Delete.
On 24/02/2024 03:33, Fangrui Song wrote:
> From: Fangrui Song
>
> Targets that are not arm*-*-uclinuxfdpiceabi can use -S -mfdpic, but -c
> -mfdpic does not pass --fdpic to gas. This is an unnecessary
> restriction. Just define the ASM_SPEC in bpabi.h.
>
> Additionally, use armelf[b]_linux_fdp
пт, 4 окт. 2024 г. в 19:07, Christophe Lyon :
>
> On Fri, 4 Oct 2024 at 16:59, Siarhei Volkau wrote:
> >
> > Hello,
> >
> > пт, 4 окт. 2024 г. в 16:48, Christophe Lyon :
> > >
> > > Hi!
> > >
> > >
> > > On Mon, 8 Jul 2024 at 10:57, Siarhei Volkau wrote:
> > > >
> > > > ping
> > > >
> > > > чт,
On Fri, 4 Oct 2024 at 16:59, Siarhei Volkau wrote:
>
> Hello,
>
> пт, 4 окт. 2024 г. в 16:48, Christophe Lyon :
> >
> > Hi!
> >
> >
> > On Mon, 8 Jul 2024 at 10:57, Siarhei Volkau wrote:
> > >
> > > ping
> > >
> > > чт, 20 июн. 2024 г. в 12:09, Siarhei Volkau :
> > > >
> > > > This patch deals wi
Hello,
пт, 4 окт. 2024 г. в 16:48, Christophe Lyon :
>
> Hi!
>
>
> On Mon, 8 Jul 2024 at 10:57, Siarhei Volkau wrote:
> >
> > ping
> >
> > чт, 20 июн. 2024 г. в 12:09, Siarhei Volkau :
> > >
> > > This patch deals with consequences but not the root cause though.
> > >
> > > There are 5 cases whic
Hi!
On Mon, 8 Jul 2024 at 10:57, Siarhei Volkau wrote:
>
> ping
>
> чт, 20 июн. 2024 г. в 12:09, Siarhei Volkau :
> >
> > This patch deals with consequences but not the root cause though.
> >
> > There are 5 cases which are subjects to rewrite:
> > case #1:
> > mov ip, r1
> > add r2, ip
> >
On Fri, Sep 27, 2024 at 2:11 PM Andre Vieira (lists)
wrote:
>
>
>
> On 26/09/2024 18:56, Ramana Radhakrishnan wrote:
> >
>
> >> +/* Helper function to determine whether SEQ represents a sequence of
> >> + instructions representing the Armv8.1-M Mainline conditional arithmetic
> >> + instruct
On 26 September 2024 20:51:55 CEST, Fangrui Song wrote:
>On Thu, Sep 26, 2024 at 11:21 AM Ramana Radhakrishnan
> wrote:
>>
>> On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
>> >
>> > From: Fangrui Song
>> >
>> > -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
>> > for
On 27 September 2024 16:05:01 CEST, "Richard Earnshaw (lists)"
wrote:
>On 26/09/2024 19:21, Ramana Radhakrishnan wrote:
>> On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
>>>
>>> From: Fangrui Song
>>>
>>> -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
>>> for FDPIC (
On 26/09/2024 19:21, Ramana Radhakrishnan wrote:
> On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
>>
>> From: Fangrui Song
>>
>> -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
>> for FDPIC (absolute addressing for symbol references and no function
>> descriptor). The
On 26/09/2024 18:56, Ramana Radhakrishnan wrote:
+/* Helper function to determine whether SEQ represents a sequence of
+ instructions representing the Armv8.1-M Mainline conditional arithmetic
+ instructions: csinc, csneg and csinv. The cinc instruction is generated
+ using a diffe
On Thu, Sep 26, 2024 at 11:21 AM Ramana Radhakrishnan
wrote:
>
> On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
> >
> > From: Fangrui Song
> >
> > -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
> > for FDPIC (absolute addressing for symbol references and no function
>
On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
>
> From: Fangrui Song
>
> -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
> for FDPIC (absolute addressing for symbol references and no function
> descriptor). The sh port simply upgrades -fno-pic to -fpie by setting
> fl
> On 25 Sep 2024, at 7:38 PM, Andre Vieira (lists)
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi,
>
> This patch restores missed optimizations for armv8.1-m.main targets that
> were missed when the generation of csinc, csinv and csneg were enabled
> or the sa
Hi,
This patch restores missed optimizations for armv8.1-m.main targets that
were missed when the generation of csinc, csinv and csneg were enabled
or the same with patch series containing:
commit c2bb84be4a6e581bbf45891457ee632a07416982
Author: Sudi Das
Date: Fri Sep 18 15:47:46 2020 +010
Friendly ping :)
On Thu, Aug 22, 2024 at 7:09 PM Fangrui Song wrote:
>
> On Mon, May 13, 2024 at 2:21 PM Fangrui Song wrote:
> >
> > On Mon, Mar 4, 2024 at 12:13 AM Fangrui Song wrote:
> > >
> > > From: Fangrui Song
> > >
> > > -fno-pic -mfdpic generated code is like regular -fno-pic, not suit
On Arm only r0-r3 (the argument registers) and IP are available for
use as an address for an indirect sibcall. But if all the argument
registers are used and IP is clobbered during the epilogue, or is used
to pass closure information, then there is no spare register to hold
the address and we must
On 21/08/2024 17:03, Christophe Lyon wrote:
> With MVE, vmov.f64 is always supported (no need for +fp.dp extension).
>
> This patch updates two patterns:
> - in movdi_vfp, we incorrectly checked
> TARGET_VFP_SINGLE || TARGET_HAVE_MVE instead of
> TARGET_VFP_SINGLE && !TARGET_HAVE_MVE, and didn
1 - 100 of 1098 matches
Mail list logo
