Hi Alexandre!
Thank you for looking into this so promptly!
On 2023-12-07T00:33:59-0300, Alexandre Oliva wrote:
> On Dec 6, 2023, Alexandre Oliva wrote:
>
>> Disabling the runtime bits is easy, once we determine what condition we
>> wish to test for. I suppose testing for target support in the
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:41, ezra.sito...@arm.com wrote:
Add xN variants of vld1_types intrinsic.
On Dec 7, 2023, FX Coudert wrote:
> The commit
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f0a90c7d7333fc7f554b906245c84bdf04d716d7
> (Introduce strub: machine-independent stack scrubbing) has introduced
> many test failures on x86_64-apple-darwin21:
Please give the followup commit f908368d
Add SME (Scalable Matrix Extension) support to libgcc.
Szabolcs Nagy (4):
libgcc: aarch64: Configure check for .variant_pcs support
libgcc: aarch64: Configure check for __getauxval
libgcc: aarch64: Add SME runtime support
libgcc: aarch64: Add SME unwinder support
libgcc/config.in
Ideally SME support routines in libgcc are marked as variant PCS symbols
so check if as supports the directive.
---
libgcc/config.in| 3 +++
libgcc/configure| 39 +++
libgcc/configure.ac | 17 +
3 files changed, 59 insertions(+)
diff --
Add configure check for the __getauxval ABI symbol, which is always
available on aarch64 glibc, and may be available on other linux C
runtimes. For now only enabled on glibc, others have to override it
target_configargs=libgcc_cv_have___getauxval=yes
This is deliberately obscure as it should be
The call ABI for SME (Scalable Matrix Extension) requires a number of
helper routines which are added to libgcc so they are tied to the
compiler version instead of the libc version. See
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#sme-support-routines
The routines are in sh
To support the ZA lazy save scheme, the PCS requires the unwinder to
reset the SME state to PSTATE.SM=0, PSTATE.ZA=0, TPIDR2_EL0=0 on entry
to an exception handler. We use the __arm_za_disable SME runtime call
unconditionally to achieve this.
https://github.com/ARM-software/abi-aa/blob/main/aapcs64
On 12/7/23 09:04, Roger Sayle wrote:
Hi Jeff,
Doh! Great catch. The perils of not (yet) being able to actually
run any ARC execution tests myself.
ACK.
Shouldn't operands[4] be GEN_INT ((HOST_WIDE_INT_1U << tmp) - 1)?
Yes(-ish), operands[4] should be GEN_INT(HOST_WIDE_INT_1U << (tmp
On Thu, Dec 7, 2023 at 11:18 AM Liao Shihua wrote:
>
> In accordance with the suggestions of Christoph Müllner, the following
> amendments are made
>
> Update v1 -> v2:
> 1. Rename *_intrinsic-* to *_intrinsic-XLEN.
> 2. Typo fix.
> 3. Intrinsics with immediate arguments will use marcos at
> However, I'm very surprised that you're hitting this with the initial
> commit. It's as if strub support was disabled on the target, but even
> if you were hitting this with e.g. offloading, only the followup commit
> introduced code to disable strub for such targets as nvptx. Anyway, do
> you
It seems like you forgot to prefix the commit message with "libgccjit:
".
On Thu, 2023-11-30 at 10:55 +0100, Guillaume Gomez wrote:
> Ping David. :)
>
> Le jeu. 23 nov. 2023 à 22:59, Antoni Boucher a
> écrit :
> > David: I found back the comment you made. Here it is:
> >
> > I see you have p
On Dec 7, 2023, FX Coudert wrote:
> The commit
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f0a90c7d7333fc7f554b906245c84bdf04d716d7
> (Introduce strub: machine-independent stack scrubbing) has introduced
> many test failures on x86_64-apple-darwin21:
Nevermind, the followup patch I'd sugges
On Thu, 9 Nov 2023 at 19:44, Victor Do Nascimento
wrote:
>
> Create the necessary mappings from the ACLE-defined Neon intrinsics
> names[1] to the internal builtin function names.
>
> [1] https://arm-software.github.io/acle/neon_intrinsics/advsimd.html
Hi Victor,
It seems this patch broke kernel b
Hi Tobias!
On Wed, 6 Dec 2023 12:36:34 +0100
Tobias Burnus wrote:
> Hi Julian,
>
> LGTM, except for:
>
> * The 'target exit data' handling - comments below - looks a bit
> fishy/inconsistent.
>
> I intent to have a closer look with more code context, but maybe you
> should have a look at it a
Szabolcs Nagy writes:
> The call ABI for SME (Scalable Matrix Extension) requires a number of
> helper routines which are added to libgcc so they are tied to the
> compiler version instead of the libc version. See
> https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#sme-support-r
On Thu, Nov 23, 2023 at 11:01 PM Richard Sandiford
wrote:
>
> Manolis Tsamis writes:
> > The existing implementation of need_cmov_or_rewire and
> > noce_convert_multiple_sets_1 assumes that sets are either REG or SUBREG.
> > This commit enchances them so they can handle/rewire arbitrary set
> >
On Dec 7, 2023, Thomas Schwinge wrote:
> Thank you for looking into this so promptly!
You're welcome ;-)
> during IPA pass: emutls
> [...]/source-gcc/gcc/testsuite/c-c++-common/strub-unsupported-3.c:18:1:
> internal compiler error: in verify_curr_properties, at passes.cc:2198
Aah, t
Thanks for addressing my comments. I have reviewed this and the other
patch before and they LGTM. I however do not have approval rights so you
will need the OK from a maintainer.
Thanks for doing this :)
Andre
On 30/11/2023 12:55, Stamatis Markianos-Wright wrote:
Hi Andre,
Thanks for the co
The 12/07/2023 17:36, Richard Sandiford wrote:
> Szabolcs Nagy writes:
> > +
> > +#include "auto-target.h"
> > +#include
> > +
sorry, this seems to fail when building --without-headers
i will respin this, handling the 'inhibit_libc' case.
Committed!
On 12/6/2023 8:22 AM, Palmer Dabbelt wrote:
On Tue, 05 Dec 2023 16:39:06 PST (-0800), e...@rivosinc.com wrote:
Ran the test case at 122e7b4f9d0c2d54d865272463a1d812002d0a5c where
the xfail
That's the original port submission, I'm actually kind of surprised it
still builds/works at
Clean up scan dump failures Juzhe mentioned could be ignored for now
with vector enabled. This will help reduce noise and make it more obvious
if a bug or regression is introduced. The failures that are still reported
are either execution failures or failures that are also present on armv8-a+sve
g
On Dec 6, 2023, Jan Hubicka wrote:
>> On Nov 30, 2023, Jan Hubicka wrote:
>>
>> >> + if (VAR_P (replaced))
>> >> + varpool_node::create_alias (sym_node->decl, replacement);
>> >> + else
>> >> + cgraph_node::create_alias (sym_node->decl, replacement);
>>
>> Unfortunately, this change
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The changes in r14-6198-g5e8a30d8b8f4d7 were broken, as I used
_GLIBCXX17_CONSTEXPR for the 'if _GLIBCXX17_CONSTEXPR (true)' condition,
forgetting that it would also be used for the is_constant_evaluated()
check. Using 'if constexpr (std::is_constant
Tested x86_64-linux. Pushed to trunk. I'll backport this too.
-- >8 --
In r14-5922-g6c8f2d3a08bc01 I added to ,
so that uintptr_t is declared if that header is compiled as a header
unit. I used because that's what already includes,
so it seemed simpler to be consistent. However, this means tha
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This local typedef for uintptr_t was accidentally named uint64_t,
probably from a careless code completion shortcut. We don't need the
typedef at all since it's only used once. Just use __UINTPTR_TYPE__
directly instead.
libstdc++-v3/ChangeLog:
On 12/7/23 09:59, Christoph Müllner wrote:
On Thu, Dec 7, 2023 at 11:18 AM Liao Shihua wrote:
In accordance with the suggestions of Christoph Müllner, the following
amendments are made
Update v1 -> v2:
1. Rename *_intrinsic-* to *_intrinsic-XLEN.
2. Typo fix.
3. Intrinsics with i
On 12/7/23 09:33, Hans-Peter Nilsson wrote:
Date: Mon, 4 Dec 2023 12:58:03 +0100 (CET)
From: Richard Biener
On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote:
Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET)
From: Richard Biener
I read from your messages that the testcases pass on arm*-*-*?
Yes: t
On 12/7/23 05:15, Robin Dapp wrote:
LGTM.
Btw your vsetvl patch from yesterday fixes the vectorized
strlen/strcmp problems. Those use vleff as first instruction.
Definitely good news.
jeff
On Dec 6, 2023, Jan Hubicka wrote:
> I am sorry for sending this late.
No need to be sorry. Thank you very much for taking the time to review
and comment on it.
> I think the ipa changes are generally fine.
Phew :-)
>> +static inline bool
>> +strub_always_inline_p (cgraph_node *node)
>> +{
On Dec 6, 2023, Jan Hubicka wrote:
> There is also access attribute which speaks directly about individual
> arugments, perhaps you want to drop this one too?
Ah, I've looked a little into it, and now I have a vague recollection of
why I don't mess with them: they only apply to arguments of poi
On 12/6/23 02:27, Jiufu Guo wrote:
Hi,
The issue mentioned in PR112525 would be able to be handled by
updating dse.cc to treat arg_pointer_rtx similarly with frame_pointer_rtx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271#c10 also mentioned
this idea.
This patch fixes 64 ICEs in full coverage testing since they happens due to
same reason.
Before this patch:
internal compiler error: in expand_const_vector, at config/riscv/riscv-v.cc:1270
appears 400 times in full coverage testing report.
The root cause is we didn't support interleave vector
Hi.
This patch fixes getting the size of size_t (bug 112910).
There's one issue with this patch: like every other feature that checks
for target-specific stuff, it requires a compilation before actually
fetching the size of the type.
Which means that getting the size before a compilation might be
Hi.
This patches update gcc_jit_context_new_array_type to take the size as
an unsigned long instead of a int, to allow creating bigger array
types.
I haven't written the ChangeLog yet because I wasn't sure it's allowed
to change the type of a function like that.
If it isn't, what would you suggest
Hi.
This patch changes the function is_int to return false on vector types.
Thanks for the review.
From 60ebfb998bd349ca2f05b115de5452378027e4de Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Thu, 26 Oct 2023 19:17:55 -0400
Subject: [PATCH] libgccjit: Make is_int return false on vector types
Hi.
This patch adds checks gcc_jit_block_add_assignment_op to make sure it
is only ever called on numeric types.
With the previous patch, this might require a change to also allow
vector types here.
Thanks for the review.
From 932048619671c61af224708a3da484b9f54a30a3 Mon Sep 17 00:00:00 2001
From
On 11/28/23 00:43, HAO CHEN GUI wrote:
Hi,
This patch passes down the equality only flags from
emit_block_cmp_hints to cmpmem optab so that the target specific expand
can generate optimized insns for equality only compare. Targets
(e.g. rs6000) can generate more efficient insn sequence if t
Cncrete bindings were using -1 and -2 in the offset field to signify
deleted and empty hash slots, but these are valid values, leading to
assertion failures inside hash_map::put on a debug build, and probable
bugs in a release build.
(gdb) call k.dump(true)
start: -2, size: 1, next: -1
(gdb) p k.
On 12/5/23 01:12, Fei Gao wrote:
op=[PLUS, MINUS, IOR, XOR]
Conditional op, if zero
rd = (rc == 0) ? (rs1 op rs2) : rs1
-->
czero.nez rd, rs2, rc
op rd, rs1, rd
Conditional op, if non-zero
rd = (rc != 0) ? (rs1 op rs2) : rs1
-->
czero.eqz rd, rs2, rc
op rd, rs1, rd
Co-authored-by: Xiao Zeng
On Thu, 2023-12-07 at 17:26 -0500, Antoni Boucher wrote:
> Hi.
> This patch fixes getting the size of size_t (bug 112910).
>
> There's one issue with this patch: like every other feature that
> checks
> for target-specific stuff, it requires a compilation before actually
> fetching the size of the
On Thu, 2023-12-07 at 17:29 -0500, Antoni Boucher wrote:
> Hi.
> This patches update gcc_jit_context_new_array_type to take the size
> as
> an unsigned long instead of a int, to allow creating bigger array
> types.
>
> I haven't written the ChangeLog yet because I wasn't sure it's
> allowed
> to c
On Thu, 2023-12-07 at 17:32 -0500, Antoni Boucher wrote:
> Hi.
> This patch changes the function is_int to return false on vector
> types.
> Thanks for the review.
Thanks; looks good to me
Dave
Can I merge this on master even though we're not in phase 1 anymore?
On Thu, 2023-12-07 at 20:07 -0500, David Malcolm wrote:
> On Thu, 2023-12-07 at 17:32 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch changes the function is_int to return false on vector
> > types.
> > Thanks for the review.
On Thu, 2023-12-07 at 17:34 -0500, Antoni Boucher wrote:
> Hi.
> This patch adds checks gcc_jit_block_add_assignment_op to make sure
> it
> is only ever called on numeric types.
>
> With the previous patch, this might require a change to also allow
> vector types here.
>
> Thanks for the review.
On Thu, Dec 07, 2023 at 11:30:16AM +0100, Iain Buclaw wrote:
> Hi,
>
> Thanks for this.
>
> Excerpts from Yang Yujie's message of Dezember 1, 2023 11:08 am:
> > diff --git a/gcc/d/dmd/cond.d b/gcc/d/dmd/cond.d
> > index 568b639e0b6..02af0cc9e29 100644
> > --- a/gcc/d/dmd/cond.d
> > +++ b/gcc/d/dm
On Thu, Dec 07, 2023 at 11:34:28AM +0100, Iain Buclaw wrote:
>
> Just a nitpick, I'd thought the committing of switchcontext.S should
> come before this. I have no strong opinion either way.
>
> OK to commit.
>
> Iain.
Thanks for the suggestion, indeed this makes sense.
Yujie
Hi,
The "fctid" is supported on 64-bit Power processors and PowerPC476. It
need a guard to check it. The patch fixes the issue.
Compared with last version,
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639536.html
the main change is to change the target requirement in pr88558*.c.
On Thu, Dec 07, 2023 at 10:18:47AM +0100, Florian Weimer wrote:
> * Yang Yujie:
>
> > With this patch, I also noticed a few errors in building unpatched older
> > software like expect-5.45.4, perl-5.28.3 and bash-5.0. Will this also be
> > the case when GCC 14 gets released?
>
> For Fedora, we k
在 2023/12/7 下午8:20, Xi Ruoyao 写道:
There seems no real reason to require -mexplicit-relocs=always for
-mcmodel=extreme or model attribute. As the linker does not know how to
relax a 3-operand la.local or la.global pseudo instruction, just emit
explicit relocs for SYMBOL_PCREL64, and under TARGE
On Thu, Dec 07, 2023 at 04:13:51PM +0800, Xi Ruoyao wrote:
>
> I understand and I don't think adding {} is wrong. The problem is the
> indent change causes a large chunk of diff and it makes reviewing more
> difficult. Thus generally we should not mix real code change and format
> change in a co
If the function desn't clobber any sse registers or only clobber
128-bit part, then vzeroupper isn't issued before the function exit.
the status not CLEAN but ANY after the function.
Also for sibling_call, it's safe to issue an vzeroupper. Also there
could be missing vzeroupper since there's no mo
Hi Haochen,
on 2023/12/8 09:58, HAO CHEN GUI wrote:
> Hi,
> The "fctid" is supported on 64-bit Power processors and PowerPC476. It
> need a guard to check it. The patch fixes the issue.
>
> Compared with last version,
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639536.html
> the
Patch v2: Using variadic macro and add the dependency into t-riscv
In order to add other extension about vector,this patch add
unsigned int (*avail) (void) into function_group_info to determine
whether to register the intrinsic based on ISA info.
gcc/ChangeLog:
* config/riscv/riscv-vecto
2023-12-08 10:44 Feng Wang wrote:
Have run all the vector api-testing.
>Patch v2: Using variadic macro and add the dependency into t-riscv
>
>In order to add other extension about vector,this patch add
>unsigned int (*avail) (void) into function_group_info to determine
>whether to re
ping.
On Thu, Nov 16, 2023 at 6:49 PM liuhongt wrote:
>
> Update in V2:
> 1) Add some comments before the pattern.
> 2) Remove ? from view_convert.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> When I'm working on PR112443, I notice there's some misoptimization
> @@ -31,624 +31,627 @@ along with GCC; see the file COPYING3. If not see
> - OPS_INFO describes all information of return type and each
> argument type.
>
> + - AVAIL this argument is the optional for AVAIL.Determin the enable
> + of the intrinsic function.
> +
> */
> #if
2023-12-08 11:18 Kito Cheng wrote:
>> @@ -31,624 +31,627 @@ along with GCC; see the file COPYING3. If not see
>> - OPS_INFO describes all information of return type and each
>> argument type.
>>
>> + - AVAIL this argument is the optional for AVAIL.Determin the enab
Hi,
Thanks for your always kind and helpful review!!
"Kewen.Lin" writes:
> Hi Jeff,
>
> on 2023/12/6 13:24, Jiufu Guo wrote:
>> Hi,
>>
>> Trunk gcc supports more constants to be built via two instructions:
>> e.g. "li/lis; xori/xoris/rldicl/rldicr/rldic".
>> And then num_insns_constant shoul
Hi,
Thanks for your insight and helpful review!
"Kewen.Lin" writes:
> Hi Jeff,
>
> on 2023/12/6 13:24, Jiufu Guo wrote:
>> Hi,
>>
>> For constant building e.g. r120=0x, which does not fit 'li or lis',
>> 'pli' is used to build this constant via 'emit_move_insn'.
>>
>> While for a co
> Yes, I can see that. I think the patch is OK with a minor nit - can you
> please document the nothrow flag usage in TREE_CHREC in
> tree-core.h? There's a big comment doing flags documentation:
Thanks, committed with the new documentation:
https://gcc.gnu.org/g:2efe3a7de0107618397264017fb045f2
> Without comma, there is a warning "warning: ISO C++11 requires at least one
> argument for the "..." in a variadic macro".
> So I add the comma.
Oh, thanks, I wasn't aware that, maybe take one more argument to '...'
#define DEF_RVV_FUNCTION(NAME, SHAPE, PREDS, ...)
Anyway my intention is to r
On 2023-12-08 10:04, chenglulu wrote:
在 2023/12/7 下午8:20, Xi Ruoyao 写道:
There seems no real reason to require -mexplicit-relocs=always for
-mcmodel=extreme or model attribute. As the linker does not know how to
relax a 3-operand la.local or la.global pseudo instruction, just emit
explicit rel
2023-12-08 11:35 Kito Cheng wrote:
>> Without comma, there is a warning "warning: ISO C++11 requires at least one
>> argument for the "..." in a variadic macro".
>> So I add the comma.
>
>Oh, thanks, I wasn't aware that, maybe take one more argument to '...'
>
>#define DEF_RVV_FUNCTION(NAME, S
On Wed, Dec 6, 2023 at 3:52 PM Richard Biener
wrote:
>
> On Wed, Dec 6, 2023 at 3:33 AM Jiang, Haochen wrote:
> >
> > > -Original Message-
> > > From: Jiang, Haochen
> > > Sent: Friday, December 1, 2023 4:51 PM
> > > To: Richard Biener
> > > Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ;
>
Since loop vectorizer won't call better_main_loop_than_p if
!flag_vect_cost_model.
Committed as it is obvious.
gcc/ChangeLog:
* config/riscv/riscv-vector-costs.cc (costs::better_main_loop_than_p):
Remove redundant check.
---
gcc/config/riscv/riscv-vector-costs.cc | 3 ---
1 file chan
On Thu, Dec 7, 2023 at 6:52 PM Alexandre Oliva wrote:
>
> On Dec 7, 2023, Thomas Schwinge wrote:
>
> > Thank you for looking into this so promptly!
>
> You're welcome ;-)
>
>
> > during IPA pass: emutls
> > [...]/source-gcc/gcc/testsuite/c-c++-common/strub-unsupported-3.c:18:1:
> > inte
On Thu, 7 Dec 2023, Hans-Peter Nilsson wrote:
> > Date: Mon, 4 Dec 2023 12:58:03 +0100 (CET)
> > From: Richard Biener
>
> > On Sat, 2 Dec 2023, Hans-Peter Nilsson wrote:
> > > > Date: Fri, 1 Dec 2023 08:07:14 +0100 (CET)
> > > > From: Richard Biener
> > > > I read from your messages that the te
Hi all,
This patch will mention the following changes in wwwdocs for x86_64 backend:
- AVX10.1 support
- APX EGPR, PUSH2POP2, PPX and NDD support
- Xeon Phi ISAs deprecated
Also I adjust the words in x86_64 part for GCC 13. Ok for gcc-wwwdocs?
Thx,
Haochen
Mention AVX10.1 support, APX su
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
PR target/112904
* config/i386/mmx.md (*xop_pcmov_): New define_insn.
gcc/testsuite/ChangeLog:
* g++.target/i386/pr112904.C: New test.
---
gcc/config/i386/mmx.md
Hi,
Jeff Law writes:
> On 12/6/23 02:27, Jiufu Guo wrote:
>> Hi,
>>
>> The issue mentioned in PR112525 would be able to be handled by
>> updating dse.cc to treat arg_pointer_rtx similarly with frame_pointer_rtx.
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271#c10 also mentioned
>> this i
On Thu, Dec 07, 2023 at 11:54:01AM +0100, Jakub Jelinek wrote:
> On Thu, Dec 07, 2023 at 09:36:23AM +0100, Jakub Jelinek wrote:
> > Without the dg-skip-if I got on 64-bit host:
> > cc1: out of memory allocating 571230784744 bytes after a total of 2772992
> > bytes
>
> I've looked at this and the
Pushed to r14-6303 and r14-6304.
在 2023/12/5 上午10:30, Lulu Cheng 写道:
1. Rebase Xi Ruoyao's patch a to the latest commit.
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636798.html
2. remove the #if
!defined(IN_LIBGCC2) && !defined(IN_TARGET_LIBS) && !defined(IN_RTS)
guards in loongarch
On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> On Thu, Dec 07, 2023 at 11:54:01AM +0100, Jakub Jelinek wrote:
> > On Thu, Dec 07, 2023 at 09:36:23AM +0100, Jakub Jelinek wrote:
> > > Without the dg-skip-if I got on 64-bit host:
> > > cc1: out of memory allocating 571230784744 bytes after a total of 27
Hi!
For casts from integers to floating point,
simplify_float_conversion_using_ranges uses SCALAR_INT_TYPE_MODE
and queries optabs on the optimization it wants to make.
That doesn't really work for large/huge BITINT_TYPE, those have BLKmode
which is not scalar int mode. Querying an optab is not
Hi!
Before bitint lowering, the IL has:
b.0_1 = b;
_2 = -b.0_1;
_3 = (unsigned _BitInt(512)) _2;
a.1_4 = a;
a.2_5 = (unsigned _BitInt(512)) a.1_4;
_6 = _3 * a.2_5;
on the first function. Now, gimple_lower_bitint has an optimization
(when not -O0) that it avoids assigning underlying VA
101 - 177 of 177 matches
Mail list logo
