Re: [PATCH] testsuite: Avoid running incompatible Arm tests

On 12/07/2024 09:02, Torbjörn SVENSSON wrote: > Ok for trunk and releases/gcc-14? > > -- > > Overriding the -mpfu and -mfloat-abi might be incompatible with selected > multilib. As a result, verify that the current multilib is compatible > with the effective target without changing the -mfpu or -

Re: [PATCH v2 1/2] arm: [MVE intrinsics] fix vdup iterator

On 11/07/2024 10:36, Christophe Lyon wrote: > This patch fixes a bug where the mode iterator for mve_vdup > should be MVE_VLD_ST instead of MVE_vecs: V2DI and V2DF (thus vdup.64) > are not supported by MVE. > > 2024-07-02 Jolen Li > Christophe Lyon > > gcc/ > * config/a

Re: [PATCH v2 2/2] arm: [MVE intrinsics] Improve vdupq_n implementation

On 11/07/2024 10:36, Christophe Lyon wrote: > This patch makes the non-predicated vdupq_n MVE intrinsics use > vec_duplicate rather than an unspec. This enables the compiler to > generate better code sequences (for instance using vmov when > possible). > > The patch renames the existing mve_vdup

Re: [PATCH] testsuite: Allow vst1 instruction

On 19/07/2024 16:10, Torbjorn SVENSSON wrote: > > > On 2024-07-19 16:36, Richard Earnshaw (lists) wrote: >> On 19/07/2024 14:07, Torbjörn SVENSSON wrote: >>> Ok for trunk and releases/gcc-14? >>> >>> -- >>> >>> On Cortex-A7 with -mf

Re: [PATCH v2] testsuite: Verify r0-r3 are extended with CMSE

On 06/05/2024 12:50, Torbjorn SVENSSON wrote: > Hi, > > Forgot to mention when I sent the patch that I would like to commit it to the > following branches: > > - releases/gcc-11 > - releases/gcc-12 > - releases/gcc-13 > - releases/gcc-14 > - trunk > Well you can [commit it to the release branc

Re: [PATCH v2] testsuite: Verify r0-r3 are extended with CMSE

point. I was only thinking about the broadening of the test to the other argument registers when I said that. So, just to be clear, OK all. R. > > Unless you have an objection, I would like to go ahead and just backport it > to all branches. > > Kind regards, > Torbjörn >

RFC: Support for pragma clang loop interleave_count(N)

Hi, We got a question as to whether GCC had something similar to llvm's pragma clang loop interleave_count(N), see https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations I did a quick hack, using 'GCC interleaves N', just as a proof of concept, to see wheth

Re: RFC: Support for pragma clang loop interleave_count(N)

On 04/06/2024 12:50, Richard Biener wrote: On Tue, 4 Jun 2024, Andre Vieira (lists) wrote: Hi, We got a question as to whether GCC had something similar to llvm's pragma clang loop interleave_count(N), see https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop

Re: [PATCH] testsuite: Avoid running neon test on Cortex-M55

I'm not a maintainer but I'd argue the entire test is bogus. The error reporting in this area seems to be somewhat fragile, if you compile it with '-march=armv7-a -mfloat-abi=soft', you also don't get the error this is testing for.  I'd argue this kind of user friendly error message should jus

rtl: Enable the use of rtx values with int and mode attributes

Hi, The 'code' part of a 'define_code_attr' refers to the type of the key, in other words, it uses a code_iterator to pick the value from their (key "value") pair list. Though it seems rtx_alloc_for_name requires a code_attribute to be used when the 'value' needs to be a type. In other words,

Re: [PATCH] arm: Always use vmov.f64 instead of vmov.f32 with MVE

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

Re: [PATCH] testuite: Accept vmov.f64

On 21/08/2024 17:06, Christophe Lyon wrote: > On Wed, 14 Aug 2024 at 22:04, Torbjörn SVENSSON > wrote: >> >> Ok for trunk and releases/gcc-14? >> >> -- >> >> On Cortex-M55 with fpv5-d16, the vmov.f64 instruction is used. > > Hi Torbjorn, > > Thanks for the patch: after looking further I realized

Re: [PATCH] testsuite: Avoid running neon test on Cortex-M55

On 13/08/2024 17:18, Andre Vieira (lists) wrote: > I'm not a maintainer but I'd argue the entire test is bogus. > > The error reporting in this area seems to be somewhat fragile, if you compile > it with '-march=armv7-a -mfloat-abi=soft', you also don't get t

arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

Hi, This patch adds missing assembly directives to the CMSE library wrapper to call functions with attribute cmse_nonsecure_call. Without the .type directive the linker will fail to produce the correct veneer if a call to this wrapper function is to far from the wrapper itself. The .size wa

Re: arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

On 05/06/2024 17:07, Andre Vieira (lists) wrote: > Hi, > > This patch adds missing assembly directives to the CMSE library wrapper to > call functions with attribute cmse_nonsecure_call.  Without the .type > directive the linker will fail to produce the correct veneer if a

Re: [PATCH] arm: Fix CASE_VECTOR_SHORTEN_MODE for thumb2.

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

Re: [PATCH v2 1/2] arm: Zero/Sign extends for CMSE security on Armv8-M.baseline [PR115253]

Hi Torbjorn, Thanks for this, I have some comments below. On 07/06/2024 09:56, Torbjörn SVENSSON wrote: Properly handle zero and sign extension for Armv8-M.baseline as Cortex-M23 can have the security extension active. Currently, there is a internal compiler error on Cortex-M23 for the epilog p

Re: [PATCH v2 1/2] arm: Zero/Sign extends for CMSE security on Armv8-M.baseline [PR115253]

Hi, So, you talk about gen_thumb1_extendhisi2, but there is also gen_thumb1_extendqisi2. Will it actually be cleaner if the block is indented one level? The comment can be added in the "if (TARGET_THUMB1)" block regardless to indicate that gen_rtx_SIGN_EXTEND can't be used. gen_rtx_SIGN_EX

Re: [PATCH v3 1/2] arm: Zero/Sign extends for CMSE security on Armv8-M.baseline [PR115253]

On 10/06/2024 15:04, Torbjörn SVENSSON wrote: > Properly handle zero and sign extension for Armv8-M.baseline as > Cortex-M23 can have the security extension active. > Currently, there is an internal compiler error on Cortex-M23 for the > epilog processing of sign extension. > > This patch addresse

Re: [PATCH v3 2/2] testsuite: Fix expand-return CMSE test for Armv8.1-M [PR115253]

On 10/06/2024 15:04, Torbjörn SVENSSON wrote: > For Armv8.1-M, the clearing of the registers is handled differently than > for Armv8-M, so update the test case accordingly. > > gcc/testsuite/ChangeLog: > > PR target/115253 > * gcc.target/arm/cmse/extend-return.c: Update test case >

Re: [PATCH v3 1/2] arm: Zero/Sign extends for CMSE security on Armv8-M.baseline [PR115253]

On 11/06/2024 14:59, Richard Earnshaw (lists) wrote: You effectively have an 'else if' split across a comment here, and the indentation looks weird. Either write 'else if' on one line (and re-indent accordingly) or put this entire block inside braces. Apologies here,

Re: [PATCH] [testsuite] [arm] test board cflags in multilib.exp

On 07/06/2024 05:47, Alexandre Oliva wrote: > > multilib.exp tests for multilib-altering flags in a board's > multilib_flags and skips the test, but if such flags appear in the > board's cflags, with the same distorting effects on tested multilibs, > we fail to skip the test. > > Extend the skipp

Re: arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

On 06/06/2024 12:53, Richard Earnshaw (lists) wrote: On 05/06/2024 17:07, Andre Vieira (lists) wrote: Hi, This patch adds missing assembly directives to the CMSE library wrapper to call functions with attribute cmse_nonsecure_call.  Without the .type directive the linker will fail to

Re: [PATCH v2] Arm: Fix disassembly error in Thumb-1 relaxed load/store [PR115188]

On 11/06/2024 17:35, Wilco Dijkstra wrote: > Hi Christophe, > >> PR target/115153 > I guess this is typo (should be 115188) ? > > Correct. > >> +/* { dg-options "-O2 -mthumb" } */-mthumb is included in arm_arch_v6m, so I >> think you don't need to add it > here? > > Indeed, it's not s

Re: arm: Add .type and .size to __gnu_cmse_nonsecure_call [PR115360]

On 12/06/2024 09:53, Andre Vieira (lists) wrote: > > > On 06/06/2024 12:53, Richard Earnshaw (lists) wrote: >> On 05/06/2024 17:07, Andre Vieira (lists) wrote: >>> Hi, >>> >>> This patch adds missing assembly directives to the CMSE library wra

Re: [RFC PATCH] ARM: thumb1: Use LDMIA/STMIA for DI/DF loads/stores

Hi Siarahei, On 16/06/2024 09:51, Siarhei Volkau wrote: > If the address register is dead after load/store operation it looks > beneficial to use LDMIA/STMIA instead of pair of LDR/STR instructions, > at least if optimizing for size. > > E.g. > ldr r0, [r3, #0] > ldr r1, [r3, #4] @ r3 is dead

Re: [PATCH v2] ARM: thumb1: Use LDMIA/STMIA for DI/DF loads/stores

On 18/06/2024 19:14, Siarhei Volkau wrote: > If the address register is dead after load/store operation it looks > beneficial to use LDMIA/STMIA instead of pair of LDR/STR instructions, > at least if optimizing for size. > > Changes v1 -> v2: > - switching to peephole2 approach > - added test ca

Re: [PATCH 0/2] arm, doloop: Add support for MVE Tail-Predicated Low Overhead Loops

On 23/05/2024 15:37, Andre Vieira wrote: > > Hi, > > We held these two patches back in stage 4 because they touched > target-agnostic code, though I am quite confident they will not affect other > targets. Given stage one has reopened, I am reposting them, I rebased them > but they seem to a

Re: [PATCH v2] Arm: Fix ldrd offset range [PR115153]

On 11/06/2024 17:42, Wilco Dijkstra wrote: > v2: use a new arm_arch_v7ve_neon, fix use of DImode in output_move_neon > > The valid offset range of LDRD in arm_legitimate_index_p is increased to > -1024..1020 if NEON is enabled since VALID_NEON_DREG_MODE includes DImode. > Fix this by moving the LD

Re: [PATCH] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]

On 13/06/2024 10:23, Alexandre Oliva wrote: > > The test was too optimistic, alas. We used to vectorize shifts > involving 8-bit and 16-bit integral types by clamping the shift count > at the highest in-range shift count, but that was not correct: such > narrow shifts expect integral promotion, s

Re: [PATCH v2] ARM: thumb1: Use LDMIA/STMIA for DI/DF loads/stores

On 19/06/2024 16:11, Siarhei Volkau wrote: > ср, 19 июн. 2024 г. в 15:19, Richard Earnshaw (lists) > : >> >> On 18/06/2024 19:14, Siarhei Volkau wrote: >>> If the address register is dead after load/store operation it looks >>> beneficial to use LDMIA/STMIA ins

Re: [PATCH v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]

On 21/06/2024 08:57, Alexandre Oliva wrote: > On Jun 20, 2024, Christophe Lyon wrote: > >> Maybe using >> if ((unsigned)b[i] >= BITS) \ >> would be clearer? > > Heh. Why make it simpler if we can make it unreadable, right? :-D > > Thanks, here's another version I've just retested on x-arm-eabi

Re: [PATCH v3] [testsuite] [arm] [vect] adjust mve-vshr test [PR113281]

On 24/06/2024 12:35, Alexandre Oliva wrote: > On Jun 21, 2024, Christophe Lyon wrote: > >>> How about mentioning Christophe's simplification in the commit log? > >> For the avoidance of doubt: it's OK for me (but you don't need to >> mention my name in fact ;-) > > Needing or not, I added it ;-

[PATCH] arm: make arm_predict_doloop_p reject loops with calls

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 not considering for doloop optimization and it is used by

Re: [PATCH] arm: make arm_predict_doloop_p reject loops with calls

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 >

mve: Fix vsetq_lane for 64-bit elements with lane 1 [PR 115611]

This patch fixes the backend pattern that was printing the wrong input scalar register pair when inserting into lane 1. Added a new test to force float-abi=hard so we can use scan-assembler to check correct codegen. Regression tested arm-none-eabi with -march=armv8.1-m.main+mve/-mfloat-abi=ha

Re: [wwwdocs] Add aarch64 11.5.0 caveat

On 23/07/2024 11:39, Richard Biener wrote: On Tue, 23 Jul 2024, Jakub Jelinek wrote: Hi! Richi suggested to mention the PR116029 bug in 11.5.0 caveats as we can't fix that anymore. Here is a patch for that, which attempts to describe (my limited understanding of) the issue. As TARGET_CPU_gene

Re: [PATCH] arm: Update fp16-aapcs-[24].c after insn_propagation patch

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

arm: Prevent ICE when doloop dec_set is not PLUS_EXPR

This patch refactors and fixes an issue where arm_mve_dlstp_check_dec_counter was making an assumption about the form of what a candidate for a dec_insn. It also makes sure that if it does not initially encounter a 'set' in such a form it tries to find another set that could be the right one.

Re: arm: Prevent ICE when doloop dec_set is not PLUS_EXPR

Hi Christophe, Thanks for the comments, attached new version for testcase, see below new cover letter: This patch refactors and fixes an issue where arm_mve_dlstp_check_dec_counter was making an assumption about the form of what a candidate for a dec_insn. This dec_insn is the instruction th

Re: arm: Prevent ICE when doloop dec_set is not PLUS_EXPR

This patch refactors and fixes an issue where arm_mve_dlstp_check_dec_counter was making an assumption about the form of what a candidate for a dec_insn should be, which caused an ICE. This dec_insn is the instruction that decreases the loop counter inside a decrementing loop a

[PATCH] arm: Fix testism with mve/ivopts-3.c testcase

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 rejected for different reasons. gcc/testsuite/ChangeLog:

Re: [PATCH] arm: Fix testism with mve/ivopts-3.c testcase

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

Re: [PATCH] arm: Fix testism with mve/ivopts-3.c testcase

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

Re: [PATCH 01/15] arm: [MVE intrinsics] improve comment for orrq shape

Hi Christophe, Maybe this patch was based on an older source, but the comment now reads: /* _t vfoo[t0](_t, _t) _t vfoo[_n_t0](_t, _t) Where the _n form only supports s16/s32/u16/u32 types as for vorrq. Example: vorrq. int16x8_t [__arm_]vorrq[_s16](int16x8_t a, int16x8_t b) int1

Re: [PATCH 03/15] arm: [MVE intrinsics] Cleanup arm-mve-builtins-functions.h

Hi, This looks great to me, only one small suggestion, but take it or leave it I think it's a matter of preference. On 11/07/2024 22:42, Christophe Lyon wrote: + /* No predicate, no suffix. */ if (e.type_suffix (0).integer_p) if (e.type_suffix (0).unsigne

Re: [PATCH 05/15] arm: [MVE intrinsics] add vcvt shape

On 11/07/2024 22:42, Christophe Lyon wrote: + bool + check (function_checker &c) const override + { +if (c.mode_suffix_id == MODE_none) + return true; + +unsigned int bits = c.type_suffix (0).element_bits; +return c.require_immediate_range (1, 1, bits); + } When trying t

Re: [PATCH] [testsuite] [arm] require arm_v8_1m_main for pacbti tests

On 16/04/2024 04:48, Alexandre Oliva wrote: > > arm pac and bti tests that use -march=armv8.1-m.main get an implicit > -mthumb, that is incompatible with vxworks kernel mode. Declaring the > requirement for a 8.1-m.main-compatible toolchain is enough to avoid > those fails, because the toolchain

Re: [testsuite] [aarch64] Require fpic effective target

On 16/04/2024 04:08, Alexandre Oliva wrote: > Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-, > aarch64-, x86- and x86_64-vxworks7r2. Ok to install? > > Co-authored-by: Olivier Hainque > > for gcc/testsuite/ChangeLog > > * gcc.target/aarch64/pr94201.c: Add missing >

Re: [PATCH] [testsuite] [arm] accept empty init for bfloat16

On 16/04/2024 04:50, Alexandre Oliva wrote: > > Complete r13-2205, adjusting an arm-specific test that expects a > no-longer-issued error at an empty initializer. > > Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-, > aarch64-, x86- and x86_64-vxworks7r2. Ok to install? > > >

Re: [PATCH]AArch64: remove reliance on register allocator for simd/gpreg costing. [PR114741]

On 18/04/2024 11:11, Tamar Christina wrote: > Hi All, > > In PR114741 we see that we have a regression in codegen when SVE is enable > where > the simple testcase: > > void foo(unsigned v, unsigned *p) > { > *p = v & 1; > } > > generates > > foo: > fmovs31, w0 > and

Re: [PATCH] [testsuite] [arm] require arm_v8_1m_main for pacbti tests

On 19/04/2024 13:45, Alexandre Oliva wrote: > On Apr 16, 2024, "Richard Earnshaw (lists)" wrote: > >> The require-effective-target flags test whether a specific set of >> flags will make the compilation work, so they need to be used in >> conjunction with the

Re: [PATCH] arm: Zero/Sign extends for CMSE security

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

Re: [PATCH] arm: Zero/Sign extends for CMSE security

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

Re: [PATCH][GCC] aarch64: Fix SCHEDULER_IDENT for Cortex-A510

On 25/04/2024 15:59, Richard Ball wrote: > Hi Richard, > > I committed this combined patch (with Cortex-A520) for trunk > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=cab53aae43cf94171b01320c08302e47a5daa391 > >

Re: [PATCH] testsuite: Verify r0-r3 are extended with CMSE

On 27/04/2024 15:13, Torbjörn SVENSSON wrote: > Add regression test to the existing zero/sign extend tests for CMSE to > verify that r0, r1, r2 and r3 are properly extended, not just r0. > > Test is done using -O0 to ensure the instructions are in a predictable > order. > > gcc/testsuite/ChangeLo

Re: [PATCH] testsuite: Verify r0-r3 are extended with CMSE

On 30/04/2024 16:37, Torbjorn SVENSSON wrote: > > > On 2024-04-30 17:11, Richard Earnshaw (lists) wrote: >> On 27/04/2024 15:13, Torbjörn SVENSSON wrote: >>> Add regression test to the existing zero/sign extend tests for CMSE to >>> verify that r0, r1, r2 and r

[wwwdocs] Specify AArch64 BitInt support for little-endian only

Hey Jakub, This what ya had in mind? Kind regards, Andre Vieiradiff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index ca5174de991bb088f653468f77485c15a61526e6..924e045a15a78b5702a0d6997953f35c6b47efd1 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html

Re: [PATCH] aarch64: Fix typo in aarch64-ldp-fusion.cc:combine_reg_notes [PR114936]

On 03/05/2024 15:45, Alex Coplan wrote: > This fixes a typo in combine_reg_notes in the load/store pair fusion > pass. As it stands, the calls to filter_notes store any > REG_FRAME_RELATED_EXPR to fr_expr with the following association: > > - i2 -> fr_expr[0] > - i1 -> fr_expr[1] > > but then

Re: [PATCH] testsuite: Sanitize pacbti test cases for Cortex-M

On 03/09/2024 13:57, Christophe Lyon wrote: > Hi Torbjörn, > > > On 9/3/24 11:30, Torbjörn SVENSSON wrote: >> >> Ok for trunk and releases/gcc-14? >> >> -- >> >> Some of the test cases were scanning for "bti", but it would, >> incorrectly, match the ".arch_extenssion pacbti". >> Also, keep test

Re: [PATCH] Fix aarch64 bootstrap (pr69416)

On 22/01/16 17:07, Richard Henderson wrote: > The bare CONST_INT inside the CCmode IF_THEN_ELSE is causing combine to > make incorrect simplifications. At this stage it feels safer to wrap > the CONST_INT inside of an UNSPEC than make more generic changes to > combine. > > But we should definitel

Re: [PING^2][PATCHv2, ARM, libgcc] New aeabi_idiv function for armv6-m

Ping. On 27/10/15 17:03, Andre Vieira wrote: Ping. BR, Andre On 13/10/15 18:01, Andre Vieira wrote: This patch ports the aeabi_idiv routine from Linaro Cortex-Strings (https://git.linaro.org/toolchain/cortex-strings.git), which was contributed by ARM under Free BSD license. The new aeabi_idi

Re: [RFC][PATCH , ARM 2/8] Add RTL patterns for thumb1 push/pop

On 26/12/15 01:45, Thomas Preud'homme wrote: [Sending on behalf of Andre Vieira] Hello, This patch adds RTL patterns for the push and pop instructions for thumb1. These are needed by subsequent patches in the series. *** gcc/ChangeLog *** 2015-10-27 Andre Vieira Thomas P

[PING] Re: [RFC][PATCH, ARM 3/8] Handling ARMv8-M Security Extension's cmse_nonsecure_entry attribute

On 26/12/15 01:47, Thomas Preud'homme wrote: [Sending on behalf of Andre Vieira] Hello, This patch adds support for the ARMv8-M Security Extensions 'cmse_nonsecure_entry' attribute. In this patch we implement the attribute handling and diagnosis around the attribute. See Section 5.4 of ARM®v8

[PATCHv2] Re: [RFC][PATCH, ARM 1/8] Add support for ARMv8-M's Security Extensions flag and intrinsics

On 05/01/16 14:38, Andre Vieira wrote: On 31/12/15 20:54, Joseph Myers wrote: On Sat, 26 Dec 2015, Thomas Preud'homme wrote: +#define CMSE_TT_ASM(flags) \ +{ \ + cmse_address_info_t result; \ + __asm__ ("tt" # flags " %0,%1" \ + : "=r"(result) \ + : "r"(p) \ + : "memory");

[PING] Re: [RFC][PATCH, ARM 4/8] ARMv8-M Security Extension's cmse_nonsecure_entry: __acle_se label and bxns return

On 26/12/15 01:52, Thomas Preud'homme wrote: [Sending on behalf of Andre Vieira] Hello, This patch extends support for the ARMv8-M Security Extensions 'cmse_nonsecure_entry' attribute in two ways: 1) Generate two labels for the function, the regular function name and one with the function's

[PING] Re: [RFC][PATCH, ARM 5/8] ARMv8-M Security Extension's cmse_nonsecure_entry: clear registers

On 26/12/15 01:54, Thomas Preud'homme wrote: [Sending on behalf of Andre Vieira] Hello, This patch extends support for the ARMv8-M Security Extensions 'cmse_nonsecure_entry' attribute to safeguard against leak of information through unbanked registers. When returning from a nonsecure entry f

[PING] Re: [RFC][PATCH, ARM 6/8] Handling ARMv8-M Security Extension's cmse_nonsecure_call attribute

On 26/12/15 01:55, Thomas Preud'homme wrote: [Sending on behalf of Andre Vieira] Hello, This patch adds support for the ARMv8-M Security Extensions 'cmse_nonsecure_call' attribute. This attribute may only be used for function types and when used in combination with the '-mcmse' compilation fl

[PING] Re: [RFC][PATCH, ARM 8/8] Added support for ARMV8-M Security Extension cmse_nonsecure_caller intrinsic

On 26/12/15 01:59, Thomas Preud'homme wrote: [Sending on behalf of Andre Vieira] Hello, This patch adds support ARMv8-M's Security Extension's cmse_nonsecure_caller intrinsic. This intrinsic is used to check whether an entry function was called from a non-secure state. See Section 5.4.3 of AR

[PATCHv2] Re: [RFC][PATCH, ARM 7/8] ARMv8-M Security Extension's cmse_nonsecure_call: use __gnu_cmse_nonsecure_call]

On 19/01/16 15:28, Andre Vieira (lists) wrote: On 16/01/16 14:49, Senthil Kumar Selvaraj wrote: User-agent: mu4e 0.9.13; emacs 24.5.1 Hi, Apologies for the bad posting style (I don't have the original email handy), but shouldn't _gnu_cmse_nonsecure_call be defined with the .global

Re: Fix PR69752, insn with REG_INC being removed as equiv_init insn

On 12/02/16 07:43, Jeff Law wrote: On 02/11/2016 06:28 PM, Bernd Schmidt wrote: This seems fairly straightforward: (insn 213 455 216 6 (set (reg:SI 266) (mem/u/c:SI (post_inc:SI (reg/f:SI 267)) [4 S4 A32])) 748 {*thumb1_movsi_insn} (expr_list:REG_EQUAL (const_int -1044200508 [0x

Re: [PATCH ARM] RFC: PR69770 -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

On 12/02/16 14:56, Charles Baylis wrote: > When compiling with -mlong-calls and -pg, calls to the __gnu_mcount_nc > function are not generated as long calls. > > This is encountered when building an allyesconfig Linux kernel because > the Linux build system generates very large sections by partial

[Ping][PATCH][GCC-5] Fix "#pragma GCC pop_options" warning.

On 18/01/16 11:04, Andre Vieira (lists) wrote: Hi there, Can we have the "#pragma GCC pop_options" fix backported to GCC-5? Patch found in https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01261.html and was committed in r228794. The same patch applies cleanly to gcc-5, which would oth

Re: [PATCH][ARM] Add initial support for the Cortex-A32

On 24/02/16 10:49, Kyrill Tkachov wrote: > Hi all, > > This patch adds initial support for the Cortex-A32 core. > It is an ARMv8-A core and this patch enables the -mcpu=cortex-a32 and > -mtune=cortex-a32 options. > > The initial tunings are set to the same parameters as for Cortex-A35. > > Boots

[WWWDocs] Deprecate support for non-thumb ARM devices

After discussion with the ARM port maintainers we have decided that now is probably the right time to deprecate support for versions of the ARM Architecture prior to ARMv4t. This will allow us to clean up some of the code base going forwards by being able to assume: - Presence of half-word data ac

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On 24/02/16 17:38, Joseph Myers wrote: > On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: > >> After discussion with the ARM port maintainers we have decided that now >> is probably the right time to deprecate support for versions of the ARM >> Architecture prior to

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On 25/02/16 13:32, Stefan Ring wrote: > On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) > wrote: >> The point is to permit the compiler to use interworking compatible >> sequences of code when generating ARM code, not to force users to use >> Thumb code. The n

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On 25/02/16 14:15, David Brown wrote: > On 25/02/16 14:32, Stefan Ring wrote: >> On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) >> wrote: >>> The point is to permit the compiler to use interworking compatible >>> sequences of code when generating AR

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On 24/02/16 13:59, Richard Earnshaw (lists) wrote: > After discussion with the ARM port maintainers we have decided that now > is probably the right time to deprecate support for versions of the ARM > Architecture prior to ARMv4t. This will allow us to clean up some of > the cod

Re: [PATCH][ARM][wwwdocs] Mention Cortex-A32 and Cortex-A35 support in changes.html for GCC 6

On 26/02/16 14:25, Kyrill Tkachov wrote: > Hi all, > > This patch adds a note to changes.html about the added support for > Cortex-A32 and Cortex-A35. > > Ok to commit? > OK. R. > Thanks, > Kyrill > > wwwdocs-a32-a35.patch > > > Index: htdocs/gcc-6/changes.html > ==

Re: [Ping^2][PATCH][GCC-5] Fix "#pragma GCC pop_options" warning.

On 15/02/16 10:33, Andre Vieira (lists) wrote: On 18/01/16 11:04, Andre Vieira (lists) wrote: Hi there, Can we have the "#pragma GCC pop_options" fix backported to GCC-5? Patch found in https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01261.html and was committed in r228794. The

Re: [PATCH][ARM] PR target/70008

On 29/02/16 11:21, Michael Collison wrote: > > > On 2/29/2016 4:06 AM, Kyrill Tkachov wrote: >> Hi Michael, >> >> On 29/02/16 04:47, Michael Collison wrote: >>> This patches address PR 70008, where a reverse subtract with carry >>> instruction can be generated in thumb2 mode. It was tested with n

Re: [PATCH] Fix PR69951

On 01/03/16 10:49, Richard Biener wrote: > On Tue, 1 Mar 2016, Ramana Radhakrishnan wrote: > >> >> >> On 01/03/16 09:54, Richard Biener wrote: >>> On Tue, 1 Mar 2016, James Greenhalgh wrote: >>> On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote: > On Mon, 29 Feb 2016, James G

Re: [PATCH][ARM] PR target/70014

On 01/03/16 17:33, Michael Collison wrote: > This patches addresses PR 70014, where the predicates and operand do not > match and could cause problems with the register allocator. Tested > successfully on > > arm-none-linux-gnueabi > arm-none-linux-gnuabihf > armeb-none-linux-gnuabihf > arm-none-e

[PATCH 0/2][GCC][ARM] Add support for Cortex-R8

Hi there, This patch series adds support for the recently announced ARM core Cortex-R8. Andre Vieira(2) Add support for Cortex-R8 Fix testcases after introduction of Cortex-R8 Tested by comparing regression runs of Cortex-R7 vs Cortex-R8 for both ARM and THUMB modes. Is this OK? Cheers, Andre

[PATCH 1/2][GCC][ARM] Add support for Cortex-R8

gcc/ChangeLog: 2016-03-02 Andre Vieira * config/arm/arm-cores.def (cortex-r8): New. * config/arm/arm-tables.opt (cortex-r8): New. * config/arm/arm-tune.md: Regenerate. * gcc/doc/invoke.texi: Add cortex-r8 to list of cpu values. >From 8d10507bd80fd0a1db221669a67785f57ffc304

[PATCH 2/2][GCC][ARM] Fix testcases after introduction of Cortex-R8

Hi, Tests used to check for "r8" which will not work because cortex-r8 string is now included in the assembly. Fixed by checking for "[^\-]r8". Is this Ok? Cheers, Andre gcc/testsuite/ChangeLog: 2016-03-02 Andre Vieira * gcc.target/arm/pr45701-1.c: Change assembler scan to not tr

Re: [patch, testsuite, ARM] don't try to execute simd.exp tests on targets without NEON

On 21/05/15 10:01, Kyrill Tkachov wrote: > Hi Sandra, > > On 21/05/15 06:43, Sandra Loosemore wrote: >> This is another patch aimed at fixing bugs relating to trying to execute >> NEON code on a target that doesn't support it revealed by my >> arm-none-eabi testing on a gazillion different multili

Re: [Ping^2][PATCH][GCC-5] Fix "#pragma GCC pop_options" warning.

On 29/02/16 10:47, Andre Vieira (lists) wrote: > On 15/02/16 10:33, Andre Vieira (lists) wrote: >> On 18/01/16 11:04, Andre Vieira (lists) wrote: >>> Hi there, >>> >>> Can we have the "#pragma GCC pop_options" fix backported to GCC-5? >>> >

Re: [PATCH][ARM] PR target/70008

er_operand (op) || (TARGET_ARM && arm_immediate_operand (op)) R. > On 02/29/2016 08:29 AM, Richard Earnshaw (lists) wrote: >> On 29/02/16 11:21, Michael Collison wrote: >>> >>> On 2/29/2016 4:06 AM, Kyrill Tkachov wrote: >>>> Hi Michael, >>

Re: [Ping^2][PATCH][GCC-5] Fix "#pragma GCC pop_options" warning.

On 03/03/16 12:11, Bernd Schmidt wrote: > On 03/03/2016 11:45 AM, Andre Vieira (lists) wrote: >> On 29/02/16 10:47, Andre Vieira (lists) wrote: >>> On 15/02/16 10:33, Andre Vieira (lists) wrote: >>>> On 18/01/16 11:04, Andre Vieira (lists) wrote: >>>&

Re: [PATCH] configure: Require C++11 for building code generation tools

On 20/08/2020 18:07, Vaseeharan Vinayagamoorthy wrote: > Hi Szabolcs, > > In the top level gcc config.log, I see: > > configure:5541: checking whether aarch64-none-linux-gnu-g++ supports C++11 > features by default > configure:5837: aarch64-none-linux-gnu-g++ -c -g -O2 conftest.cpp >&5 > config

Re: [PATCH] aarch64: Allow -mcpu=generic -march=armv8.5-a

On 17/02/2020 15:42, Richard Sandiford wrote: "Richard Earnshaw (lists)" writes: On 14/02/2020 10:41, Andrew Pinski wrote: On Fri, Feb 14, 2020 at 2:12 AM Richard Earnshaw (lists) wrote: On 14/02/2020 03:18, apin...@marvell.com wrote: From: Andrew Pinski Right if someone

Re: [PATCH] aarch64: Allow -mcpu=generic -march=armv8.5-a

On 17/02/2020 17:54, Andrew Pinski wrote: On Mon, Feb 17, 2020 at 7:56 AM Richard Earnshaw (lists) wrote: On 17/02/2020 15:42, Richard Sandiford wrote: "Richard Earnshaw (lists)" writes: On 14/02/2020 10:41, Andrew Pinski wrote: On Fri, Feb 14, 2020 at 2:12 AM Richard Earns

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 27/02/2020 13:37, Nathan Sidwell wrote: On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote: On 22/01/2020 17:45, Richard Earnshaw (lists) wrote: [updated based on v2 discussions] This patch proposes some new (additional) rules for email subject lines when contributing to GCC.  The goal is

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 02/03/2020 14:41, Jonathan Wakely wrote: On Mon, 2 Mar 2020 at 14:31, Nathan Sidwell wrote: On 3/2/20 8:01 AM, Richard Earnshaw (lists) wrote: On 27/02/2020 13:37, Nathan Sidwell wrote: On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote: On 22/01/2020 17:45, Richard Earnshaw (lists

Re: [committed][ARM] Fix minor testsuite fallout on ARM due to recent IRA changes

On 02/03/2020 15:46, Jeff Law wrote: More minor fallout from Vlad's IRA changes. Previously this test used r3 to hold a value across a call (it's an ipa-ra test). After Vlad's changes we're using r1 instead. This patch makes the obvious change to pattern we can for which should bring the test

Re: [committed][ARM] Fix minor testsuite fallout on ARM due to recent IRA changes

On 02/03/2020 16:44, Jeff Law wrote: On Mon, 2020-03-02 at 16:40 +, Richard Earnshaw (lists) wrote: On 02/03/2020 15:46, Jeff Law wrote: More minor fallout from Vlad's IRA changes. Previously this test used r3 to hold a value across a call (it's an ipa-ra test). After Vlad

[committed] libgcc: arm: convert thumb1 code to unified syntax

Unified syntax has been the official syntax for thumb1 assembly for over 10 years now. It's time we made preparations for that becoming the default in the assembler. But before we can start doing that we really need to clean up some laggards from the olden days. Libgcc support for thumb1 is

Re: [PATCH 2/2] [aarch64] Rework fpcr fpsr getter/setter builtins

On 11/03/2020 13:50, Szabolcs Nagy wrote: On 10/03/2020 09:55, Andrea Corallo wrote: Hi all, second and last patch of the two reworking FPCR and FPSR builtins. This rework __builtin_aarch64_set_fpcr (unsigned) and __builtin_aarch64_set_fpsr (unsigned) to emit a read-modify-sequences as:

<    1   2   3   4   5   6   7   8   9   10   >