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.
>
>
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
>
>
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 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
>&
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
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 +, 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, that INIT_CUMULATIVE_ARGS on arm ignores
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 +, 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, that INIT_CUMULATIVE_ARGS on arm ignores
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/107453
>>> * calls.cc (expand_call): For calls with
>>> TYPE_NO_NAMED_ARGS_STDARG_P (funtype) use zero for n_named_args.
>>>
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.
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 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
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.
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_standard_branch_protection): Copy.
>>>
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
On 01/12/2023 13:45, Christophe Lyon wrote:
> On Fri, 1 Dec 2023 at 13:44, Richard Earnshaw (lists)
> wrote:
>>
>> On 01/12/2023 11:28, Saurabh Jha wrote:
>>> Hey,
>>>
>>> I introduced this test "gcc/testsuite/
On 01/12/2023 11:28, Saurabh Jha wrote:
> Hey,
>
> I introduced this test "gcc/testsuite/gcc.target/arm/mve/pr112337.c" in this
> commit 2365aae84de030bbb006edac18c9314812fc657b before. This had an error
> which I unfortunately missed. This patch fixes that test.
>
> Did regression testing on
On 22/11/2023 15:21, Maciej W. Rozycki wrote:
> Use non-capturing parentheses for the subexpressions used with
> `scan-assembler-times', to avoid a quirk with double-counting.
>
> gcc/testsuite/
> * gcc.target/aarch64/ccmp_1.c: Use non-capturing parentheses
> with
On 05/09/2023 16:00, Richard Sandiford via Gcc-patches wrote:
> Szabolcs Nagy writes:
>> Update tests for the new branch-protection parser errors.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/aarch64/branch-protection-attr.c: Update.
>> *
On 11/10/2023 14:56, Jeff Law wrote:
>
>
> On 10/11/23 04:39, Florian Weimer wrote:
>> I've started to look at what it is required to convert the testsuite to
>> C99 (without implicit ints, without implicit function declarations, and
>> a few other legacy language features).
> I bet those older
On 09/10/2023 14:12, Victor Do Nascimento wrote:
>
>
> On 10/7/23 12:53, Richard Sandiford wrote:
>> Richard Earnshaw writes:
>>> On 03/10/2023 16:18, Victor Do Nascimento wrote:
In implementing the ACLE read/write system register builtins it was
observed that leaving argument type
On 28/09/2023 12:55, Siddhesh Poyarekar wrote:
> +Security features implemented in GCC
> +
> +
[...]
> +
> +Similarly, GCC may transform code in a way that the correctness of
> +the expressed algorithm is preserved, but supplementary properties
> +
On 26/09/2023 14:46, Wilco Dijkstra wrote:
>
> The outline atomic functions have hidden visibility and can only be called
> directly. Therefore we can remove the BTI at function entry. This improves
> security by reducing the number of indirect entry points in a binary.
> The BTI markings on
On 20/09/2023 14:50, Wilco Dijkstra wrote:
>
> The cpymemdi/setmemdi implementation doesn't fully support strict alignment.
> Block the expansion if the alignment is less than 16 with STRICT_ALIGNMENT.
> Clean up the condition when to use MOPS.
>
> Passes regress/bootstrap, OK for commit?
>
On 11/09/2023 16:22, Jonathan Wakely via Gcc-patches wrote:
> On Mon, 11 Sept 2023 at 14:57, Christophe Lyon
> wrote:
>>
>>
>>
>> On Mon, 11 Sept 2023 at 15:12, Jonathan Wakely wrote:
>>>
>>> On Mon, 11 Sept 2023 at 13:36, Christophe Lyon
>>> wrote:
On Mon, 11 Sept 2023 at
On 23/08/2023 16:49, Richard Sandiford via Gcc-patches wrote:
> Richard Earnshaw via Gcc-patches writes:
>> Now that we require C++ 11, we can safely forward declare rtx_code
>> so that we can use it in target hooks.
>>
>> gcc/ChangeLog
>> * coretypes.h (rtx_code): Add forward declaration.
On 18/08/2023 17:37, FX Coudert via Gcc-patches wrote:
A rather trivial fix for fprintf() specifier of a HOST_WIDE_INT value.
Tested on aarch64-apple-darwin. OK to commit?
FX
OK.
R.
On 08/08/2023 20:39, Carlos O'Donell via Gcc-patches wrote:
On 8/8/23 13:46, David Edelsohn wrote:
I believe that upstream projects for components that are imported
into GCC should be responsible for their security policy, including
libgo, gofrontend, libsanitizer (other than local patches),
On 08/08/2023 15:40, Siddhesh Poyarekar wrote:
On 2023-08-08 10:37, Jakub Jelinek wrote:
On Tue, Aug 08, 2023 at 10:30:10AM -0400, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc, libstdc++,
etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit
On 11/07/2023 15:54, Richard Earnshaw (lists) via Gcc-patches wrote:
On 11/07/2023 10:37, Florian Weimer via Gcc-patches wrote:
libgcc/
* config/aarch64/aarch64-unwind.h (aarch64_cie_signed_with_b_key):
Add missing const qualifier. Cast from const unsigned char *
to const char
On 11/07/2023 10:37, Florian Weimer via Gcc-patches wrote:
libgcc/
* config/aarch64/aarch64-unwind.h (aarch64_cie_signed_with_b_key):
Add missing const qualifier. Cast from const unsigned char *
to const char *. Use __builtin_strchr to avoid an implicit
On 28/06/2023 10:26, Christophe Lyon via Gcc-patches wrote:
This tests currently expect a directive containing .fpu fpv5-sp-d16
and thus may fail if the test is executed for instance with
-march=armv8.1-m.main+mve.fp+fp.dp
This patch accepts either fpv5-sp-d16 or fpv5-d16 to avoid the failure.
On 28/06/2023 10:26, Christophe Lyon via Gcc-patches wrote:
If GCC is configured with the default (soft) -mfloat-abi, and we don't
override the target_board test flags appropriately,
gcc.target/arm/mve/general-c/nomve_fp_1.c fails for lack of
-mfloat-abi=softfp or -mfloat-abi=hard, because it
On 01/06/2023 05:26, YunQiang Su wrote:
speculation_barrier for MIPS needs sync+jr.hb (r2+),
so we implement __speculation_barrier in libgcc, like arm32 does.
gcc/ChangeLog:
* config/mips/mips-protos.h (mips_emit_speculation_barrier): New
prototype.
*
On 08/06/2023 11:00, Tamar Christina via Gcc-patches wrote:
Hi All,
This converts some patterns in the AArch64 backend to use the new
compact syntax.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
gcc/ChangeLog:
* config/aarch64/aarch64.md (arches):
On 08/06/2023 11:29, Richard Earnshaw (lists) via Gcc-patches wrote:
On 08/06/2023 11:12, Andreas Schwab wrote:
On Jun 08 2023, Tamar Christina via Gcc-patches wrote:
@@ -713,6 +714,183 @@ you can use @samp{*} inside of a @samp{@@}
multi-alternative template:
@end group
@end smallexample
On 08/06/2023 11:12, Andreas Schwab wrote:
On Jun 08 2023, Tamar Christina via Gcc-patches wrote:
@@ -713,6 +714,183 @@ you can use @samp{*} inside of a @samp{@@}
multi-alternative template:
@end group
@end smallexample
+@node Compact Syntax
+@section Compact Syntax
+@cindex compact
On 06/06/2023 13:49, Richard Sandiford via Gcc-patches wrote:
Tamar Christina writes:
int operand_number; /* Operand index in the big array. */
int output_format; /* INSN_OUTPUT_FORMAT_*. */
+ bool compact_syntax_p;
struct operand_data operand[MAX_MAX_OPERANDS];
On 24/04/2023 09:33, Richard Sandiford via Gcc-patches wrote:
Richard Sandiford writes:
Tamar Christina writes:
Hi All,
This patch adds support for a compact syntax for specifying constraints in
instruction patterns. Credit for the idea goes to Richard Earnshaw.
I am sending up this RFC to
On 13/01/2023 22:12, Jakub Jelinek wrote:
On Fri, Jan 13, 2023 at 09:58:26PM +, Richard Earnshaw (lists) wrote:
> I'm afraid increasing number of DWARF registers is ABI incompatible change.
> E.g. libgcc __frame_state_for function fills in:
> typedef struct frame_state
> {
&g
On 13/01/2023 18:02, Jakub Jelinek via Gcc-patches wrote:
On Fri, Jan 13, 2023 at 05:44:15PM +, Srinath Parvathaneni via Gcc-patches
wrote:
Hello,
This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo
hard-register and also
updates the ".save", ".cfi_register",
Fix a signed vs unsigned comparison in last change.
gcc:
* common/config/arm/arm-common.c (arm_config_default): Change type
of 'i' to unsigned.
---
gcc/common/config/arm/arm-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 03/03/2021 14:11, Christophe Lyon via Gcc-patches wrote:
> On Wed, 3 Mar 2021 at 14:55, Richard Earnshaw (lists)
> wrote:
>>
>> Hopefully this change will reduce the number of times Christophe is
>> needing to tweak the testsuite.
>>
>
> Thanks!
>
Hopefully this change will reduce the number of times Christophe is
needing to tweak the testsuite.
--
Arm processors can support up to two instruction sets. Some early
cores only support the traditional A32 (Arm) instructions, while some
more recent devices only support T32 (Thumb)
Commit r10-6017 relaxed the constraint on thumb2 calls to
__gnu_cmse_nonsecure_call to allow any register for the call address.
Although the initial code expansion continues to use r4 with the FPCXT
extension is not enabled, the change was unsafe because subsequent
optimizations could use the
On 10/02/2021 17:44, Andrea Corallo via Gcc-patches wrote:
> Andrea Corallo via Gcc-patches writes:
>
>> "Richard Earnshaw (lists)" writes:
>>
>>> On 09/02/2021 16:27, Andrea Corallo via Gcc-patches wrote:
>>>> Jakub Jelinek writes:
>>&
On 09/02/2021 16:27, Andrea Corallo via Gcc-patches wrote:
> Jakub Jelinek writes:
>
>> On Tue, Feb 09, 2021 at 03:09:43PM +0100, Jakub Jelinek via Gcc-patches
>> wrote:
"TARGET_32BIT && TARGET_HAVE_LOB"
- "le\t%|lr, %l0")
+ "*
+ if (get_attr_length (insn) == 4)
+
On 26/11/2020 13:53, Andrea Corallo via Gcc-patches wrote:
> Hi all,
>
> I'd like to submit the following simple patch to clean some Low Loop
> Overhead test failing on hard float configurations.
>
> lob2.c and lob5.c are failing with: "'-mfloat-abi=hard': selected
> processor lacks an FPU".
>
arm_split_atomic_op handles subtracting a constant by converting it
into addition of the negated constant. But if the type of the operand
is int and the constant is -1 we currently end up generating invalid
RTL which can lead to an abort later on.
The problem is that in a HOST_WIDE_INT, INT_MIN
On 19/11/2020 14:40, Wilco Dijkstra via Gcc-patches wrote:
> Hi,
>
As for your second patch, --with-cpu-64 could be a simple alias indeed,
but what is the exact definition/expected behaviour of a --with-cpu-32
on a target that only supports 64-bit code? The AArch64
1 - 100 of 945 matches
Mail list logo
