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
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
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
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
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/
> *
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
On 19/07/2024 14:07, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> On Cortex-A7 with -mfloat-abi=hard and -mfpu=neon, the following
> instructions are generated for the test case:
>
> vldrd16, .L3
> vst1.32 {d16}, [r0]
>
> For Cortex-A7 with
On 11/07/2024 19:31, Richard Sandiford wrote:
> These tests used to generate:
>
> bl swap
> ldr r2, [sp, #4]
> mov r0, r2 @ __fp16
>
> but g:9d20529d94b23275885f380d155fe8671ab5353a means that we can
> load directly into r0:
>
> bl swap
>
On 10/07/2024 17:26, Torbjörn SVENSSON wrote:
> Is this ok for the following branches?
> - trunk
> - releases/gcc-14
> - releases/gcc-13
>
> --
>
> Since r13-1006-g2005b9b888eeac, the test case copysign_softfloat_1.c
> no longer contains any lsr istruction, so drop the check as per
> comment 9
On 26/06/2024 13:20, Andre Vieira (lists) wrote:
> 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
On 05/07/2024 17:11, Jonathan Wakely via Gcc wrote:
> On Fri, 5 Jul 2024 at 16:54, Alejandro Colomar via Gcc
> wrote:
>> At least, I hope there's consensus that while current GCC doesn't warn
>> about this, ideally it should, which means it should warn for valid uses
>> of strtol(3), which means
On 27/06/2024 17:25, Wilco Dijkstra wrote:
> Hi Richard,
>
>> The Linaro CI is reporting an ICE while building libgfortran with this
>> change.
>
> So it looks like Thumb-2 oddly enough restricts the negative range of DFmode
> eventhough that is unnecessary and inefficient. The easiest
On 04/07/2024 13:50, Siarhei Volkau wrote:
> чт, 4 июл. 2024 г. в 12:45, Richard Earnshaw (lists)
> :
>>
>> On 20/06/2024 08:24, Siarhei Volkau wrote:
>>> If the address register is dead after load/store operation it looks
>>> beneficial to use LDMIA/STMIA ins
On 20/06/2024 08:24, 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 v2 -> v3:
> - switching to mixed approach (insn+peep2)
> -
On 27/06/2024 17:16, Wilco Dijkstra wrote:
> Hi Richard,
>
>> Doing just this will mean that the register allocator will have to undo a
>> pre/post memory operand that was accepted by the predicate (memory_operand).
>> I think we really need a tighter predicate (lets call it noautoinc_mem_op)
On 25/06/2024 20:08, Arsen Arsenović via Gcc wrote:
> Hi,
>
> Richard Biener writes:
>
>> [snip]
>>> I was also proposing (and would like to re-air that here) enforcing
>>> that the committer field of each commit is a (valid) @gcc.gnu.org
>>> email. This can be configured repo-locally via:
>>>
On 27/06/2024 13:29, Sam James via Gcc wrote:
> "Richard Earnshaw (lists)" writes:
>
>> On 24/06/2024 22:34, Sam James via Gcc wrote:
>>> Hi!
>>>
>>> This comes up in #gcc on IRC every so often, so finally
>>> writing an RFC.
>>&g
On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote:
> Hi,
>
> Sam James via Gcc writes:
>
>> Hi!
>>
>> This comes up in #gcc on IRC every so often, so finally
>> writing an RFC.
>>
>> What?
>> ---
>>
>> I propose that MAINTAINERS be modified to be of the form,
>> adding an extra field for their
On 24/06/2024 22:34, Sam James via Gcc wrote:
> Hi!
>
> This comes up in #gcc on IRC every so often, so finally
> writing an RFC.
>
> What?
> ---
>
> I propose that MAINTAINERS be modified to be of the form,
> adding an extra field for their GCC/sourceware account:
>
On 25/06/2024 12:53, Andre Vieira (lists) wrote:
> Hi,
>
> With the introduction of low overhead loops in
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3dfc28dbbd21b1d708aa40064380ef4c42c994d7
> we defined arm_predict_doloop_p, this is meant to be a low-weight check to
> rule out loops we
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
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
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
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,
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
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
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
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
On 12/06/2024 14:23, Mikael Morin via Gcc wrote:
> Le 12/06/2024 à 14:58, Jonathan Wakely a écrit :
>> On Wed, 12 Jun 2024 at 13:57, Mikael Morin via Gcc wrote:
>>>
>>> Le 12/06/2024 à 13:48, Jakub Jelinek a écrit :
Hi!
Yesterday the gcc git repository was locked for 3 hours
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
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
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.
>
>
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
>
> ____
1 - 100 of 1165 matches
Mail list logo
