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 23/04/2024 09:56, Mark Wielaard wrote:
> Hi,
>
> On Mon, Apr 22, 2024 at 11:51:00PM -0400, Jason Merrill wrote:
>> On Mon, Apr 22, 2024 at 11:24 PM Tom Tromey wrote:
>>> Jason> Someone mentioned earlier that gerrit was previously tried
>>> Jason> unsuccessfully.
>>>
>>> We tried it and gdb
On 23/04/2024 04:24, Tom Tromey wrote:
> Jason> Someone mentioned earlier that gerrit was previously tried
> Jason> unsuccessfully.
>
> We tried it and gdb and then abandoned it. We tried to integrate it
> into the traditional gdb development style, having it send email to
> gdb-patches. I
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 03/04/2024 14:23, Christophe Lyon via Gcc wrote:
> On Wed, 3 Apr 2024 at 14:59, Joel Sherrill wrote:
>>
>> Another possible issue which may be better now than in years past
>> is that the versions of autoconf/automake required often had to be
>> installed by hand. I think newlib has gotten
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 15:04, Andrew Carlotti via Gcc wrote:
> On Thu, Feb 29, 2024 at 06:39:54PM +0100, Christophe Lyon via Gcc wrote:
>> On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote:
>>>
>>> Hi Christophe,
>>>
>>> On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote:
I've
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 04/03/2024 20:04, Jonathan Wakely wrote:
> On Mon, 4 Mar 2024 at 19:27, Vladimir Mezentsev
> wrote:
>>
>>
>>
>> On 3/4/24 09:38, Richard Earnshaw (lists) wrote:
>>> Tools like git (and svn before it) don't try to maintain time-stamps on
>&
On 04/03/2024 16:42, Christophe Lyon wrote:
> On Mon, 4 Mar 2024 at 16:41, Richard Earnshaw
> wrote:
>>
>>
>>
>> On 04/03/2024 15:36, Richard Earnshaw (lists) wrote:
>> > On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
>> >> On Mon,
On 04/03/2024 14:46, Christophe Lyon via Gcc wrote:
> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote:
>>
>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrote:
>>>
>>> Hi!
>>>
>>> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
Hi!
On
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 29/02/2024 10:22, Christophe Lyon via Gcc wrote:
> Hi!
>
> Sorry for cross-posting, but I'm not sure the rules/guidelines are the
> same in gcc vs binutils/gdb.
>
> TL;DR: are there some guidelines about how to use/enable maintainer-mode?
>
> In the context of the Linaro CI, I've been
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 14/12/2023 07:17, Surya Kumari Jangala via Gcc wrote:
> Hi Richard,
> Thanks a lot for your response!
>
> Another failure reported by the Linaro CI is as follows:
>
> Running gcc:gcc.dg/dg.exp ...
> FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump pro_and_epilogue
> "Performing
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 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 11/10/2023 09:58, Andrew Stubbs wrote:
> On 11/10/2023 07:54, Chung-Lin Tang wrote:
>>
>>
>> On 2023/10/10 11:11 PM, Andrew Stubbs wrote:
>>> Hi all,
>>>
>>> I'm trying to add a new register set to the GCN port, but I've hit a
>>> problem I don't understand.
>>>
>>> There are 256 new registers
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 10/10/2023 11:46, Richard Earnshaw (lists) via Gcc wrote:
> On 10/10/2023 10:47, Florian Weimer via Gcc wrote:
>> Currently, -fsigned-char and -funsigned-char are only documented as C
>> language options, although they work for C++ as well (and Objective-C
>> and Objective
On 10/10/2023 10:47, Florian Weimer via Gcc wrote:
> Currently, -fsigned-char and -funsigned-char are only documented as C
> language options, although they work for C++ as well (and Objective-C
> and Objective-C++, I assume, but I have not tested this). There does
> not seem to be a place for
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 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 08/09/2023 19:18, Siddhesh Poyarekar wrote:
> Hello,
>
> I want to begin by apologizing because I know from first hand experience that
> scheduling can be an immensely painful job.
>
> The Cauldron 2023 schedule[1] looks packed and I noticed that Qing and
> David's talks on security
On 06/09/2023 15:03, Iain Sandoe wrote:
> Hi Richard,
>
>> On 6 Sep 2023, at 13:43, Richard Sandiford via Gcc wrote:
>>
>> Iain Sandoe writes:
>
>>> On the Darwin aarch64 port, we have a number of cleanup test fails (pretty
>>> much corresponding to the [still open]
>>>
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 07/08/2023 16:51, Şahin Duran via Gcc wrote:
Dear GCC Developers,
I think I've just discovered a bug/ undefined situation in the compiler.
When I try to call a weakly defined function, compiler successfully
generates the code of calling procedure. However, this calling procedure is
nothing
the organisers: we will fit you in if we can, but priority
will go to those who have already submitted something.
Richard.
On 05/06/2023 16:09, Richard Earnshaw (lists) wrote:
We are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Cambridge, UK, on September 22-24, 2023
We have now finalized the ticket price for this year's Cauldron at £75.
Sarah is now contacting those who have already registered to arrange
payment.
If you have not yet registered then there is still time. Registration
closes at 12 Noon BST (7am EDT) on Friday 1st September, and all tickets
It is now just under 2 months until the GNU Tools Cauldron.
Registration is still open, but we would really appreciate it if you
could register as soon as possible so that we have a clear idea of the
numbers.
Richard.
On 05/06/2023 14:59, Richard Earnshaw wrote:
> We are pleased to invite you
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
1 - 100 of 1143 matches
Mail list logo
