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.
>
> This patch uses an approac
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
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
>
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
> 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
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
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
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/
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
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
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.
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
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 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
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 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
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 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 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
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
>
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 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
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
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
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
>
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
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
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 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
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 suitable
> > for FDPIC (absolute addressing for symbol references and no function
> > descr
Yeah true... committed.
On 01/08/2024 13:54, Christophe Lyon wrote:
On 8/1/24 12:02, Andre Vieira (lists) wrote:
On 01/08/2024 10:09, Christophe Lyon wrote:
It seems your attachment contains only the commit message but lacks
the actual patch?
I blame lack of coffee...
Thanks.
The
On 8/1/24 14:54, Christophe Lyon wrote:
On 8/1/24 12:02, Andre Vieira (lists) wrote:
On 01/08/2024 10:09, Christophe Lyon wrote:
It seems your attachment contains only the commit message but lacks
the actual patch?
I blame lack of coffee...
Thanks.
The patch LGTM. It seems patc
On 8/1/24 12:02, Andre Vieira (lists) wrote:
On 01/08/2024 10:09, Christophe Lyon wrote:
It seems your attachment contains only the commit message but lacks
the actual patch?
I blame lack of coffee...
Thanks.
The patch LGTM. It seems patchwork didn't recognize it, so Linaro CI
wi
On 01/08/2024 10:09, Christophe Lyon wrote:
It seems your attachment contains only the commit message but lacks the
actual patch?
I blame lack of coffee...
Thanks.diff --git a/gcc/testsuite/gcc.target/arm/mve/ivopts-3.c
b/gcc/testsuite/gcc.target/arm/mve/ivopts-3.c
index
19b2442ef12cbf
Hi Andre
On 8/1/24 10:46, Andre Vieira (lists) wrote:
Hi,
This patch ensures this testcase is ran for armv8.1-m.main+mve as this
is testing that doloops with function calls that aren't intrinsics get
rejected as potential doloop targets during ivopts. For other targets
this loop gets reject
On 23/07/2024 17:25, Adhemerval Zanella Netto wrote:
On 19/07/24 11:25, Richard Earnshaw (lists) wrote:
On 11/07/2024 19:31, Richard Sandiford wrote:
These tests used to generate:
bl swap
ldr r2, [sp, #4]
mov r0, r2 @ __fp16
but g:9d20529d94b23275885
On 19/07/24 11:25, Richard Earnshaw (lists) wrote:
> On 11/07/2024 19:31, Richard Sandiford wrote:
>> These tests used to generate:
>>
>> bl swap
>> ldr r2, [sp, #4]
>> mov r0, r2 @ __fp16
>>
>> but g:9d20529d94b23275885f380d155fe8671ab5353a means that we ca
On 11/07/2024 19:31, Richard Sandiford wrote:
> These tests used to generate:
>
> bl swap
> ldr r2, [sp, #4]
> mov r0, r2 @ __fp16
>
> but g:9d20529d94b23275885f380d155fe8671ab5353a means that we can
> load directly into r0:
>
> bl swap
>
On 25/06/2024 12:53, Andre Vieira (lists) wrote:
> Hi,
>
> With the introduction of low overhead loops in
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3dfc28dbbd21b1d708aa40064380ef4c42c994d7
> we defined arm_predict_doloop_p, this is meant to be a low-weight check to
> rule out loops we are
Hi Torbjörn!
On Thu, 6 Jun 2024 at 18:47, Torbjörn SVENSSON
wrote:
>
> I would like to push this patch to the following branches:
>
> - releases/gcc-11
> - releases/gcc-12
> - releases/gcc-13
> - releases/gcc-14
> - trunk
>
> Ok?
>
> The problem was highlighted by https://linaro.atlassian.net/bro
On 06/06/2024 15:40, Richard Ball wrote:
> The CASE_VECTOR_SHORTEN_MODE query is missing some equals signs
> which causes suboptimal codegen due to missed optimisation
> opportunities. This patch also adds a test for thumb2
> switch statements as none exist currently.
>
> gcc/ChangeLog:
> PR
On Mon, May 6, 2024 at 4:09 PM Fangrui Song wrote:
>
> On Wed, Mar 6, 2024 at 1:54 AM Richard Earnshaw (lists)
> wrote:
> >
> > On 06/03/2024 05:07, Fangrui Song wrote:
> > > On Fri, Feb 23, 2024 at 7:33 PM Fangrui Song wrote:
> > >>
> > >> From: Fangrui Song
> > >>
> > >> Targets that are not
Hi Wilco,
On 6/3/24 15:42, Wilco Dijkstra wrote:
A Thumb-1 memory operand allows single-register LDMIA/STMIA. This doesn't get
printed as LDR/STR with writeback in unified syntax, resulting in strange
assembler errors if writeback is selected. To work around this, use the 'Uw'
constraint that
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 suitable
> for FDPIC (absolute addressing for symbol references and no function
> descriptor). The sh port simply upgrades -fno-pic to -fpie by setting
> f
On Wed, Mar 6, 2024 at 1:54 AM Richard Earnshaw (lists)
wrote:
>
> On 06/03/2024 05:07, Fangrui Song wrote:
> > On Fri, Feb 23, 2024 at 7:33 PM Fangrui Song wrote:
> >>
> >> From: Fangrui Song
> >>
> >> Targets that are not arm*-*-uclinuxfdpiceabi can use -S -mfdpic, but -c
> >> -mfdpic does not
On Mon, 29 Apr 2024 at 15:29, Jakub Jelinek wrote:
>
> On Fri, Apr 26, 2024 at 11:10:12PM +, Christophe Lyon wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
> > @@ -0,0 +1,36 @@
> > +/* { dg-do compile } */
> > +/* { dg-require-effective-target arm_v8_1m_mve_ok }
On Fri, Apr 26, 2024 at 11:10:12PM +, Christophe Lyon wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
> @@ -0,0 +1,36 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target arm_v8_1m_mve_ok } */
> +/* { dg-add-options arm_v8_1m_mve } */
> +/* { dg-final { c
On 26/04/2024 09:39, Torbjorn SVENSSON wrote:
> Hi,
>
> On 2024-04-25 16:25, Richard Ball wrote:
>> Hi Torbjorn,
>>
>> Thanks very much for the comments.
>> I think given that the code that handles this, is within a
>> FOREACH_FUNCTION_ARGS loop.
>> It seems a fairly safe assumption that if the c
Hi,
On 2024-04-25 16:25, Richard Ball wrote:
Hi Torbjorn,
Thanks very much for the comments.
I think given that the code that handles this, is within a
FOREACH_FUNCTION_ARGS loop.
It seems a fairly safe assumption that if the code works for one that it
will work for all.
To go back and add e
Regards,
Richard Ball
From: Torbjorn SVENSSON
Sent: 25 April 2024 12:47
To: Richard Ball ; gcc-patches@gcc.gnu.org
; Richard Earnshaw ; Richard
Sandiford ; Marcus Shawcroft
; Kyrylo Tkachov
Subject: Re: [PATCH] arm: Zero/Sign extends for CMSE security
Hi,
On
Hi,
On 2024-04-24 17:55, Richard Ball wrote:
This patch makes the following changes:
1) When calling a secure function from non-secure code then any arguments
smaller than 32-bits that are passed in registers are zero- or
sign-extended.
2) After a non-secure function returns into secure co
On 24/04/2024 16:55, Richard Ball wrote:
> This patch makes the following changes:
>
> 1) When calling a secure function from non-secure code then any arguments
>smaller than 32-bits that are passed in registers are zero- or
> sign-extended.
> 2) After a non-secure function returns into secur
On 15/03/2024 20:08, Christophe Lyon wrote:
The testcase in this PR shows that we would load from an uninitialized
location, because the vld1 instrinsics are reported as "const". This
is because function_instance::reads_global_state_p() does not take
CP_READ_MEMORY into account. Fixing this g
On 06/03/2024 20:28, Alexandre Oliva wrote:
> On Mar 1, 2024, "Richard Earnshaw (lists)" wrote:
>
>> On 01/03/2024 04:38, Alexandre Oliva wrote:
>>> Thanks for the review.
>
>> For closure, Jakub has just pushed a patch to the generic code, so I
>> don't think we need this now.
>
> ACK. I see
On Wed, Mar 06, 2024 at 05:28:21PM -0300, Alexandre Oliva wrote:
> On Mar 1, 2024, "Richard Earnshaw (lists)" wrote:
>
> > On 01/03/2024 04:38, Alexandre Oliva wrote:
> >> Thanks for the review.
>
> > For closure, Jakub has just pushed a patch to the generic code, so I
> > don't think we need t
On Mar 1, 2024, "Richard Earnshaw (lists)" wrote:
> On 01/03/2024 04:38, Alexandre Oliva wrote:
>> Thanks for the review.
> For closure, Jakub has just pushed a patch to the generic code, so I
> don't think we need this now.
ACK. I see the c2x-stdarg-4.c test is now passing in our arm-eabi
gc
On 06/03/2024 05:07, Fangrui Song wrote:
> On Fri, Feb 23, 2024 at 7:33 PM 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 A
On Fri, Feb 23, 2024 at 7:33 PM 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[
On 2024-03-01 15:58, Richard Earnshaw (lists) wrote:
On 19/02/2024 09:13, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-13?
Regtested on top of 945cb8490cb for arm-none-eabi, without any regression.
Backporting to releases/gcc-13 will change -std=c23 to -std=c2x.
Jakub has just pu
On 19/02/2024 09:13, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-13?
> Regtested on top of 945cb8490cb for arm-none-eabi, without any regression.
>
> Backporting to releases/gcc-13 will change -std=c23 to -std=c2x.
Jakub has just pushed a different fix for this, so I don't think we n
On 01/03/2024 04:38, Alexandre Oliva wrote:
> Hello, Matthew,
>
> Thanks for the review.
For closure, Jakub has just pushed a patch to the generic code, so I don't
think we need this now.
R.
>
> On Feb 26, 2024, Matthew Malcomson wrote:
>
>> I think you're right that the AAPCS32 requires al
Hello, Matthew,
Thanks for the review.
On Feb 26, 2024, Matthew Malcomson wrote:
> I think you're right that the AAPCS32 requires all arguments to be passed in
> registers for this testcase.
> (Nit on the commit-message: It says that your reading of the AAPCS32
> suggests
> that the *caller* is
Hi Alexandre,
I don't have the ability to OK the patch, but I'm attempting to do a
review in
order to reduce the workload for any maintainer. (Apologies for the slow
response).
I think you're right that the AAPCS32 requires all arguments to be passed in
registers for this testcase.
(Nit on th
On 26/02/2024 16:05, Wilco Dijkstra wrote:
> Hi Richard,
>
>> Did you test this on a thumb1 target? It seems to me that the target parts
>> that you've
>> removed were likely related to that. In fact, I don't see why this test
>> would need to be changed at all.
>
> The testcase explicitly fo
Hi Richard,
> Did you test this on a thumb1 target? It seems to me that the target parts
> that you've
> removed were likely related to that. In fact, I don't see why this test
> would need to be changed at all.
The testcase explicitly forces a Thumb-2 target (arm_arch_v6t2). The patterns
wer
On 23/02/2024 15:46, Wilco Dijkstra wrote:
> Hi Richard,
>
>> This bit isn't. The correct fix here is to fix the pattern(s) concerned to
>> add the missing predicate.
>>
>> Note that builtin-bswap.x explicitly mentions predicated mnemonics in the
>> comments.
>
> I fixed the patterns in v2. Th
Hi Richard,
> This bit isn't. The correct fix here is to fix the pattern(s) concerned to
> add the missing predicate.
>
> Note that builtin-bswap.x explicitly mentions predicated mnemonics in the
> comments.
I fixed the patterns in v2. There are likely some more, plus we could likely
merge ma
On 21/02/2024 14:34, Wilco Dijkstra wrote:
>
> By default most patterns can be conditionalized on Arm targets. However
> Thumb-2 predication requires the "predicable" attribute be explicitly
> set to "yes". Most patterns are shared between Arm and Thumb(-2) and are
> marked with "predicable". G
On Mon, Feb 19, 2024 at 1:14 AM Torbjörn SVENSSON
wrote:
>
> Ok for trunk and releases/gcc-13?
> Regtested on top of 945cb8490cb for arm-none-eabi, without any regression.
>
> Backporting to releases/gcc-13 will change -std=c23 to -std=c2x.
>
> --
>
> In commit 4fe34cdcc80ac225b80670eabc38ac5e31ce
1 - 100 of 1059 matches
Mail list logo
