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
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
>
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
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:
>
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 call to
> this
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
>
> On
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
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
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
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.
>
>
*From:* Richard Ball
> *Sent:* 12 March 2024 14:08
> *To:* gcc-patches@gcc.gnu.org ; Richard Earnshaw
> ; Richard Sandiford ;
> Marcus Shawcroft
> *Subject:* [PATCH][GCC] aarch64: Fix SCHEDULER_IDENT for Cortex-A510
>
> The SCHEDULER_IDENT for this CPU was incorrectly
&g
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
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
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
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
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?
>
>
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
>
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
On 20/03/2024 11:21, Yury Khrustalev wrote:
> This patch updates `aarch64-sys-regs.def', bringing it into sync with
> the Binutils source.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-sys-regs.def: Copy from Binutils.
Thanks, I've pushed this. It's trivial enough and there's value of
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
On 15/03/2024 15:13, Thiago Jung Bauermann wrote:
Hello,
"Richard Earnshaw (lists)" writes:
On 13/01/2024 20:46, Thiago Jung Bauermann wrote:
diff --git a/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c
b/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c
index 5b
On 14/03/2024 08:37, Jakub Jelinek wrote:
Hi!
The following testcase ICEs with LSE atomics.
The problem is that the @atomic_compare_and_swap expander uses
aarch64_reg_or_zero predicate for the desired operand, which is fine,
given that for most of the modes and even for TImode in some cases
On 13/03/2024 12:12, Maxim Kuvyrkov wrote:
Changes in v2:
- Better changelog entry.
- NFC.
This patch has been tested on
- aarch64-linux-gnu
- arm-linux-gnueabihf (VFP, NEON disabled by default),
- arm-none-eabi (Soft-FP)
with the following [expected] differences in the test results:
-
On 12/03/2024 14:08, Richard Ball wrote:
The SCHEDULER_IDENT for this CPU was incorrectly
set to cortexa55, which is incorrect. This can cause
sub-optimal asm to be generated.
Ok for trunk?
gcc/ChangeLog:
PR target/114272
* config/aarch64/aarch64-cores.def (AARCH64_CORE):
On 13/03/2024 10:58, Maxim Kuvyrkov wrote:
This patch has been tested on
- aarch64-linux-gnu
- arm-linux-gnueabihf (VFP, NEON disabled by default),
- arm-none-eabi (Soft-FP)
with the following [expected] differences in the test results:
- FAIL now PASS [FAIL => PASS]:
This test was too simple, which meant that the compiler was sometimes
able to find a better optimization of the code than using a BICS
instruction. Fix this by changing the test slightly to produce a
sequence where BICS should always be the preferred solution.
gcc/testsuite:
PR
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
>&
This test generates different warnings on ilp32 targets because the size
of an integer matches the size of a pointer. Avoid this by using
signed char.
gcc/testsuite:
PR testsuite/113428
* gcc.dg/gomp/bad-array-section-c-3.c: Use signed char instead
of int.
---
I think
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
For thumb1, when using a peephole to fuse
mov reg, #const
add reg, reg, SP
into
add reg, SP, #const
we must first check that reg is a low register, otherwise we will ICE
when trying to recognize the resulting insn.
gcc/ChangeLog:
PR target/113510
*
On 19/02/2024 10:11, Saurabh Jha wrote:
>
> On 2/9/2024 2:57 PM, Richard Earnshaw (lists) wrote:
>> On 30/01/2024 17:07, Saurabh Jha wrote:
>>> Hey,
>>>
>>> Previously, this test was added to fix this bug:
>>> https://gcc.gnu.org/bugzilla/show_b
On 11/01/2024 14:35, Szabolcs Nagy wrote:
> The branch-protection types are target specific, not the same on arm
> and aarch64. This currently affects pac-ret+b-key, but there will be
> a new type on aarch64 that is not relevant for arm.
>
> After the move, change aarch_ identifiers to aarch64_
On 27/02/2024 13:56, Andre Vieira wrote:
>
> This patch adds support for MVE Tail-Predicated Low Overhead Loops by using
> the
> doloop funcitonality added to support predicated vectorized hardware loops.
>
> gcc/ChangeLog:
>
> * config/arm/arm-protos.h (arm_target_bb_ok_for_lob): Change
On 27/02/2024 13:56, Andre Vieira wrote:
>
> This patch adds support in the target agnostic doloop pass for the detection
> of
> predicated vectorized hardware loops. Arm is currently the only target that
> will make use of this feature.
>
> gcc/ChangeLog:
>
> * df-core.cc
On 27/02/2024 13:56, Andre Vieira wrote:
>
> This patch fixes the erroneous use of a mode attribute without a mode iterator
> in the pattern and removes unused unspecs and iterators.
>
> gcc/ChangeLog:
>
> * config/arm/iterators.md (supf): Remove VMLALDAVXQ_U, VMLALDAVXQ_P_U,
>
On 27/02/2024 13:56, Andre Vieira wrote:
>
> This patch annotates some MVE across lane instructions with a new attribute.
> We use this attribute to let the compiler know that these instructions can be
> safely implicitly predicated when tail predicating if their operands are
> guaranteed to have
On 27/02/2024 13:56, Andre Vieira wrote:
>
> This patch adds an attribute to the mve md patterns to be able to identify
> predicable MVE instructions and what their predicated and unpredicated
> variants
> are. This attribute is used to encode the icode of the unpredicated variant
> of
> an
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
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
On 13/01/2024 20:46, Thiago Jung Bauermann wrote:
> Since commit 2c3db94d9fd ("c: Turn int-conversion warnings into
> permerrors") the test fails with errors such as:
>
> FAIL: gcc.target/arm/acle/cde-mve-error-2.c -O0 (test for errors, line
> 32)
> FAIL:
On 01/03/2024 14:23, Andre Vieira (lists) wrote:
> Hi Thiago,
>
> Thanks for this, LGTM but I can't approve this, CC'ing Richard.
>
> Do have a nitpick, in the gcc/testsuite/ChangeLog: remove 'gcc/testsuite'
> from bullet points 2-4.
>
Yes, this is OK with the change Andre mentioned (your
On 29/02/2024 15:55, Jakub Jelinek wrote:
> On Thu, Feb 29, 2024 at 02:14:05PM +0000, Richard Earnshaw wrote:
>>> I tried the above on arm, aarch64 and x86_64 and that seems fine,
>>> including the new testcase you added.
>>>
>>
>> I should mention though
On 29/02/2024 17:56, Jakub Jelinek wrote:
> On Thu, Feb 29, 2024 at 05:51:03PM +0000, Richard Earnshaw (lists) wrote:
>> Oh, but wait! Perhaps that now falls into the initial 'if' clause and we
>> never reach the point where you pick zero. So perhaps I'm worrying about
>>
On 29/02/2024 17:55, Andrew Pinski (QUIC) wrote:
>> -Original Message-
>> From: Maxim Kuvyrkov
>> Sent: Thursday, February 29, 2024 9:46 AM
>> To: Andrew Pinski (QUIC)
>> Cc: Evgeny Karpov ; Andrew Pinski
>> ; Richard Sandiford ; gcc-
>> patc...@gcc.gnu.org; 10wa...@gmail.com;
On 29/02/2024 17:38, Jakub Jelinek wrote:
> On Thu, Feb 29, 2024 at 05:23:25PM +0000, Richard Earnshaw (lists) wrote:
>> On 29/02/2024 15:55, Jakub Jelinek wrote:
>>> On Thu, Feb 29, 2024 at 02:14:05PM +, Richard Earnshaw wrote:
>>>>> I tried the above on arm,
On 29/02/2024 15:55, Jakub Jelinek wrote:
> On Thu, Feb 29, 2024 at 02:14:05PM +0000, Richard Earnshaw wrote:
>>> I tried the above on arm, aarch64 and x86_64 and that seems fine,
>>> including the new testcase you added.
>>>
>>
>> I should mention though
On 29/02/2024 14:10, Richard Earnshaw (lists) wrote:
> On 27/02/2024 17:25, Jakub Jelinek wrote:
>> On Tue, Feb 27, 2024 at 04:41:32PM +, Richard Earnshaw wrote:
>>>> 2023-01-09 Jakub Jelinek
>>>>
>>>>PR target/10745
On 27/02/2024 17:25, Jakub Jelinek wrote:
> On Tue, Feb 27, 2024 at 04:41:32PM +0000, Richard Earnshaw wrote:
>>> 2023-01-09 Jakub Jelinek
>>>
>>> PR target/107453
>>> * calls.cc (expand_call): For calls with
>>> TYPE_NO_NAMED_A
[resending, apologies, I accidentally CC'd the wrong person last time]
On 27/02/2024 16:41, Richard Earnshaw wrote:
>
>
> On 09/01/2023 10:32, Jakub Jelinek via Gcc-patches wrote:
>> Hi!
>>
>> On powerpc64le-linux, the following patch fixes
>> -FAIL: gcc
On 09/01/2023 10:32, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> On powerpc64le-linux, the following patch fixes
> -FAIL: gcc.dg/c2x-stdarg-4.c execution test
> -FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O0 execution test
> -FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O1 execution
GCC 13's changes file documents that iwmmx is deprecated. Raise the bar
by warning when the mmintrin.h header is included by users, but provide
a way to suppress the warning.
gcc:
* config/arm/mmintrin.h: Warn if this header is included without
defining
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
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.
The expand pattern for reciprocal division was enabled for all math
optimization modes, but the patterns it was generating were not
enabled unless -funsafe-math-optimizations were enabled, this leads to
an ICE when the pattern we generate cannot be recognized.
Fixed by only enabling vector
On 21/02/2024 17:47, Evgeny Karpov wrote:
> Hello,
>
> We would like to take your attention to the review of changes for the
> new GCC target, aarch64-w64-mingw32. The new target will be
> supported, tested, added to CI, and maintained by Linaro. This marks
> the first of three planned patch
On 21/02/2024 18:40, Evgeny Karpov wrote:
>
+aarch64-*-mingw*)
This doesn't match the glob pattern you added to config.gcc in an earlier
patch, but see my comment on that. The two should really be consistent with
each other or you might get build failures late on.
R.
On 21/02/2024 18:38, Evgeny Karpov wrote:
>
For this change you might want to put some form of re-direct in the manual
under the old name so that anybody used to looking for the old entry will know
where things have been moved to. Something like
x86 Windows Options
See xref(Cygwin and MinGW
On 21/02/2024 18:36, Evgeny Karpov wrote:
>
+/* GNU as supports weak symbols on PECOFF. */
+#ifdef HAVE_GAS_WEAK
Can't we assume this is true? It was most likely needed on i386 because
support goes back longer than the assembler had this feature, but it looks like
it was added in 2000, or
On 21/02/2024 18:30, Evgeny Karpov wrote:
>
+ tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1"
I missed this on first reading...
The GCC port name uses AARCH64, please use that internally rather than other
names. The only time when we should be using ARM64 is when it's needed for
On 21/02/2024 18:30, Evgeny Karpov wrote:
>
+/* X18 reserved for the TEB on Windows. */
+#ifdef TARGET_ARM64_MS_ABI
+# define FIXED_X18 1
+# define CALL_USED_X18 0
+#else
+# define FIXED_X18 0
+# define CALL_USED_X18 1
+#endif
I'm not overly keen on ifdefs like this (and the one below), it can
On 21/02/2024 18:26, Evgeny Karpov wrote:
>
+/* Available call ABIs. */
+enum calling_abi
+{
+ AARCH64_EABI = 0,
+ MS_ABI = 1
+};
+
The convention in this file seems to be that all enum types to start with
aarch64. Also, the enumeration values should start with the name of the
enumeration
On 21/02/2024 18:16, Evgeny Karpov wrote:
>
+aarch64*-*-mingw*)
Other targets are a bit inconsistent here as well, but, as Andrew mentioned, if
you don't want to handle big-endian, it might be better to match
aarch64-*-mingw* here.
R.
On 21/02/2024 21:34, rep.dot@gmail.com wrote:
> On 21 February 2024 19:34:43 CET, Evgeny Karpov
> wrote:
>>
>
> Please use git send-email. Your mail ends up as empty as here, otherwise.
I don't see anything wrong with it; niether does patchwork
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".
On 19/02/2024 10:58, Tamar Christina wrote:
>> -Original Message-
>> From: Tamar Christina
>> Sent: Thursday, February 15, 2024 11:05 AM
>> To: Richard Earnshaw (lists) ; gcc-
>> patc...@gcc.gnu.org
>> Cc: nd ; Marcus Shawcroft ; Kyrylo
>> Tkac
On 12/02/2024 13:48, Matthieu Longo wrote:
> This patch marks a rev16 test as XFAIL for architectures having only Thumb1
> support. The generated code is functionally correct, but the optimization is
> disabled when -mthumb is equivalent to Thumb1. Fixing the root issue would
> requires changes
On 15/02/2024 10:57, Tamar Christina wrote:
> Hi All,
>
> This test has never worked on AArch64 since the day it was committed. It has
> a number of issues that prevent it from working on AArch64:
>
> 1. IEEE does not require that FP operations raise a SIGFPE for FP operations,
> only that
On 14/02/2024 09:20, Tejas Belagod wrote:
> On 2/7/24 11:41 PM, Richard Earnshaw (lists) wrote:
>> On 07/02/2024 07:59, Tejas Belagod wrote:
>>> This patch fixes a bug that causes indirect calls in PAC-enabled functions
>>> to be tailcalled incorrectly when all argume
On 13/02/2024 10:44, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-13?
The alternative approach (that is changing the result a bit) is to drop
the special treatment for arm*-*-*. I'm not sure if this is prefered or
just disable the test for incompatible flags for arm*-*-*.
--
The
On 30/01/2024 17:07, Saurabh Jha wrote:
> Hey,
>
> Previously, this test was added to fix this bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337. However, it did not
> check the compilation options before using them, leading to errors.
>
> This patch fixes the test by first checking
The v*_fp16_xN_1.c tests on Arm have been unstable since they were
added. This is not a problem with the tests themselves, or even the
patches that were added, but with the testsuite infrastructure. It
turned out that another set of dg- tests for fp16 were corrupting the
cached set of options
On 07/02/2024 07:59, Tejas Belagod wrote:
> This patch fixes a bug that causes indirect calls in PAC-enabled functions
> to be tailcalled incorrectly when all argument registers R0-R3 are used.
>
> Tested on arm-none-eabi for armv8.1-m.main. OK for trunk?
>
> 2024-02-07 Tejas Belagod
>
>
On 26/01/2024 15:31, Richard Ball wrote:
> v2: Formatting and test options fix.
>
> Adds missing bti instruction at the beginning of a virtual
> thunk, when bti is enabled.
>
> gcc/ChangeLog:
>
> * config/arm/arm.cc (arm_output_mi_thunk): Emit
> insn for bti_c when bti is enabled.
>
will fail for
> inc_src: (plus (reg LR) (const_int -n)'
> reg: (reg LR)
>
> Instead I will substitute the operand '==' with calls to 'rtx_equal_p (op1,
> op2, NULL)'.
Yes, that's fine.
R.
>
> Sound good?
>
> Kind regards,
> Andre
>
>
On 19/01/2024 14:40, Andre Vieira wrote:
>
> Respin after comments from Kyrill and rebase. I also removed an if-then-else
> construct in arm_mve_check_reg_origin_is_num_elems similar to the other
> functions
> Kyrill pointed out.
>
> After an earlier comment from Richard Sandiford I also added
On 19/01/2024 14:40, Andre Vieira wrote:
>
> Reposting for testing purposes, no changes from v2 (other than rebase).
We seem to have lost the ChangeLog for this hunk :(
The code itself looks OK, though.
and pushed this.
Could you please prepare backports for gcc-11 thru 13? It should just
be a matter of cherry-picking the commit.
R.
On 2024-01-22 16:25, Richard Earnshaw (lists) wrote:
On 22/01/2024 12:18, Matthieu Longo wrote:
rev16 pattern was not recognised anymore as a change in the bswap
On 25/01/2024 10:29, Maxim Kuvyrkov wrote:
> After fwprop improvement in r14-8319-g86de9b66480, codegen in
> bics_3.c test changed from "bics" to "bic" instruction, with
> the overall instruction stream remaining at the same quality.
>
> This patch makes the scan-assembler directive accept both
>
On 23/01/2024 15:53, Richard Ball wrote:
> Adds missing bti instruction at the beginning of a virtual
> thunk, when bti is enabled.
>
> gcc/ChangeLog:
>
> * config/arm/arm.cc (arm_output_mi_thunk): Emit
> insn for bti_c when bti is enabled.
>
> gcc/testsuite/ChangeLog:
>
>
On 22/01/2024 12:18, Matthieu Longo wrote:
> rev16 pattern was not recognised anymore as a change in the bswap tree
> pass was introducing a new GIMPLE form, not recognized by the assembly
> final transformation pass.
>
> More details in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933
>
>
On 21/01/2024 07:29, Andrew Pinski wrote:
> So the problem here is the 2 functions check_cpu and check_arch use
> the wrong variable to check if an alias is valid for that cpu/arch.
> check_cpu uses cpu_optaliases instead of cpu_opt_alias. cpu_optaliases
> is an array of index'ed by the cpuname
On 02/01/2024 09:23, ezra.sito...@arm.com wrote:
> From: Ezra Sitorus
>
> Add vld1q, vst1, vst1q and vst1 intrinsics to arm port.
>
> Ezra Sitorus (12):
> [GCC] arm: vld1q_types_x2 ACLE intrinsics
> [GCC] arm: vld1q_types_x3 ACLE intrinsics
> [GCC] arm: vld1q_types_x4 ACLE intrinsics
>
On 11/01/2024 14:43, Szabolcs Nagy wrote:
> The 12/07/2023 13:13, Richard Earnshaw wrote:
>> On 03/11/2023 15:36, Szabolcs Nagy wrote:
>>> * config/aarch64/aarch64.cc (aarch_handle_no_branch_protection): Copy.
>>> (aarch_handle_standa
On 08/01/2024 16:07, Roger Sayle wrote:
Bootstrapping GCC on arm-linux-gnueabihf with --with-arch=armv6 currently
has a large number of FAILs in libatomic (regressions since last time I
attempted this). The failure mode is related to IFUNC handling with the
file tas_8_2_.o containing an
On 08/01/2024 17:21, Matthieu Longo wrote:
Hi,
Arm GCC backend does not define __ARM_FEATURE_BF16 when +bf16 is
specified (via -march option, or target pragma) whereas it is supposed
to be tested before including arm_bf16.h (as specified in ACLE document:
On 05/01/2024 01:43, Lipeng Zhu wrote:
This patch try to fix the bug when HAVE_ATOMIC_FETCH_ADD is
not defined in dec_waiting_unlocked function. As io.h does
not include async.h, the WRLOCK and RWUNLOCK macros are
undefined.
libgfortran/ChangeLog:
* io/io.h (dec_waiting_unlocked): Use
On 15/12/2023 11:31, Lipeng Zhu wrote:
On 2023/12/14 23:50, Richard Earnshaw (lists) wrote:
On 09/12/2023 15:39, Lipeng Zhu wrote:
This patch try to introduce the rwlock and split the read/write to
unit_root tree and unit_cache with rwlock instead of the mutex to
increase CPU efficiency
On 09/12/2023 15:39, Lipeng Zhu wrote:
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to step into the insert_unit function is around
rove this ;)).
Kind regards,
Andre
From: Stamatis Markianos-Wright
Sent: Thursday, November 16, 2023 11:36 AM
To: Stamatis Markianos-Wright via Gcc-patches; Richard Earnshaw;
Richard Sandiford; Kyrylo Tkachov
Subject: [PING][PATCH 2/2] arm: Add support for MVE Tail-Predi
Pushed, thanks.
R.
On 07/12/2023 15:21, ezra.sito...@arm.com wrote:
Add xN variants of vld1q_types intrinsic.
On 06/11/2023 11:20, Stamatis Markianos-Wright wrote:
Patch has already been approved at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630326.html
... But I'm sending this again for archiving on the list after rebasing
A couple of minor nits:
1)
+#define
Sorry, Ezra, but I've taken the decision to back out all 4 of the patch
series' related to this. I think the problems that the CI has shown up
need to be addressed first, and the fixes don't seem to be entirely trivial.
R.
On 07/12/2023 16:44, Richard Earnshaw wrote:
Pushed, thanks.
R
Pushed, thanks.
R.
On 07/12/2023 15:41, ezra.sito...@arm.com wrote:
Add xN variants of vld1_types intrinsic.
Pushed, thanks.
R.
On 07/12/2023 15:36, ezra.sito...@arm.com wrote:
Add xN variants of vst1q_types intrinsic.
Pushed, thanks.
R.
On 07/12/2023 15:28, ezra.sito...@arm.com wrote:
Add xN variants of vst1_types intrinsic.
On 03/11/2023 15:36, Szabolcs Nagy wrote:
The branch-protection types are target specific, not the same on arm
and aarch64. This currently affects pac-ret+b-key, but there will be
a new type on aarch64 that is not relevant for arm.
gcc/ChangeLog:
* config/aarch64/aarch64-opts.h
On 03/11/2023 15:36, Szabolcs Nagy wrote:
Refactor the parsing to have a single API and fix a few parsing issues:
- Different handling of "bti+none" and "none+bti": these should be
rejected because "none" can only appear alone.
- Accepted empty strings such as "bti++pac-ret" or "bti+",
Sorry, I only just spotted this while looking at something else.
On 23/05/2023 15:41, Christophe Lyon via Gcc-patches wrote:
Glibc defines int32_t as 'int' while newlib defines it as 'long int'.
Although these correspond to the same size, g++ complains when using the
On 05/12/2023 10:59, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 10:57:50AM +, Richard Earnshaw wrote:
On 05/12/2023 10:51, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote:
The following patch makes libgfortran build on i686-linux after hacking up
On 05/12/2023 10:51, Jakub Jelinek wrote:
On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote:
The following patch makes libgfortran build on i686-linux after hacking up
--- kinds.h.xx 2023-12-05 00:23:00.133365064 +0100
+++ kinds.h 2023-12-05 11:19:24.409679808 +0100
1 - 100 of 2582 matches
Mail list logo
