Re: [PATCH 2/2] arm: Add cortex-m52 doc

On 2024/01/08 22:32 UTC+8, Kyrylo Tkachov wrote: -Original Message- From: Chung-Ju Wu Sent: Monday, January 8, 2024 6:17 AM To: gcc-patches ; Kyrylo Tkachov ; Richard Earnshaw Cc: jason...@anshingtek.com.tw Subject: [PATCH 2/2] arm: Add cortex-m52 doc Hi, This is the patch to

Re: [PATCH 1/2] arm: Add cortex-m52 core

On 2024/01/08 22:31 UTC+8, Kyrylo Tkachov wrote: Hi jasonwucj, -Original Message- From: Chung-Ju Wu Sent: Monday, January 8, 2024 6:16 AM To: gcc-patches ; Kyrylo Tkachov ; Richard Earnshaw Cc: jason...@anshingtek.com.tw Subject: [PATCH 1/2] arm: Add cortex-m52 core Hi, Recently,

RE: [PATCH v3] RISC-V: Bugfix for doesn't honor no-signed-zeros option

The test case pr30957-1.c first comes from this commit about 19 years ago which expect the -1.0 for testing. https://github.com/gcc-mirror/gcc/commit/290358f770d21d9204ea621f839ee8fba606a275 Then the below commit changes from -1.0 to +1.0 for this test file only, because of the instantiates

[wwwdocs][PATCH] gcc-14/changes: Update APX inline asm behavior for x86_64

Hi, This patch adds missing description for inline asm behavior and related compiler switch for APX. Ok for gcc-wwwdocs? --- htdocs/gcc-14/changes.html | 6 ++ 1 file changed, 6 insertions(+) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index e3a68998..73a90d30

[PATCH] i386: [APX] Document inline asm behavior and new switch for APX

Hi, For APX, the inline asm behavior was not mentioned in any document before. Add description for it. Ok for trunk? gcc/ChangeLog: * config/i386/i386.opt: Adjust document. * doc/invoke.texi: Add description for -mapx-inline-asm-use-gpr32. --- gcc/config/i386/i386.opt

[PATCH] Add -mevex512 into invoke.texi

Hi all, In invoke.texi, -mevex512 is missing. This patch adds that. Ok for trunk? Thx, Haochen gcc/ChangeLog: * doc/invoke.texi: Add -mevex512. --- gcc/doc/invoke.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index

Re:[pushed] [PATCH] LoongArch: Implenment vec_init where N is a LSX vector mode

Pushed to r14-7022. 在 2024/1/5 下午3:38, Jiahao Xu 写道: This patch implenments more vec_init optabs that can handle two LSX vectors producing a LASX vector by concatenating them. When an lsx vector is concatenated with an LSX const_vector of zeroes, the vec_concatz pattern can be used

Re：[PATCH v4] RISC-V: Handle differences between XTheadvector and Vector

It has been updated. [PATCH v5] RISC-V: Handle differences between XTheadvector and Vector (gnu.org) -- 发件人：钟居哲 发送时间：2024年1月9日(星期二) 07:08 收件人："cooper.joshua"; "gcc-patches" 抄　送："jim.wilson.gcc"; palmer; andrew;

[PATCH v5] RISC-V: Handle differences between XTheadvector and Vector

This patch is to handle the differences in instruction generation between Vector and XTheadVector. In this version, we only support partial xtheadvector instructions that leverage directly from current RVV1.0 with simple adding "th." prefix. For different name xtheadvector instructions but share

[Committed] RISC-V: Fix comments of segment load/store intrinsic

We have supported segment load/store intrinsics. Committed as it is obvious. gcc/ChangeLog: * config/riscv/riscv-vector-builtins-functions.def (vleff): Move comments. (vundefined): Ditto. --- gcc/config/riscv/riscv-vector-builtins-functions.def | 4 ++-- 1 file changed, 2

Re：[PATCH v4] RISC-V: Handle differences between XTheadvector and Vector

For the vsetvl issue, we have discussed last week. Maybe riscv_asm_output function cannot return instructions like riscv_output_move. The briefest approach may be to add some logic in the vsetvl patterns. Only 3 patterns need to be modified and that will not be too invasive.

[Committed] RISC-V: Fix comments of segment load/store intrinsic[NFC]

We have supported segment load/store intrinsics. Committed as it is obvious. gcc/ChangeLog: * config/riscv/riscv-vector-builtins-functions.def (vleff): Move comments to real place. (vcreate): Ditto. --- gcc/config/riscv/riscv-vector-builtins-functions.def | 4 +--- 1 file

回复: Re: [PATCH v7 1/2] RISC-V: Add crypto vector builtin function.

Committed, thanks Juzhe. 发件人： 钟居哲 发送时间： 2024-01-09 07:02 收件人： wangfeng; gcc-patches 抄送： kito.cheng; Jeff Law; wangfeng 主题： Re: [PATCH v7 1/2] RISC-V: Add crypto vector builtin function. LGTM. juzhe.zh...@rivai.ai From: Feng Wang Date: 2024-01-08 17:12 To: gcc-patches CC: kito.cheng;

回复: Re: [PATCH v8 2/2] RISC-V: Add crypto vector api-testing cases.

Committed, thanks Juzhe. 发件人： 钟居哲 发送时间： 2024-01-09 07:02 收件人： wangfeng; gcc-patches 抄送： kito.cheng; Jeff Law; wangfeng 主题： Re: [PATCH v8 2/2] RISC-V: Add crypto vector api-testing cases. LGTM. juzhe.zh...@rivai.ai From: Feng Wang Date: 2024-01-08 17:12 To: gcc-patches CC: kito.cheng;

Re: Re: [PATCH] RISC-V: Teach liveness computation loop invariant shift amount[Dynamic LMUL]

Yes. It does sufficient. Send a patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642216.html juzhe.zh...@rivai.ai From: Robin Dapp Date: 2024-01-09 00:45 To: 钟居哲; gcc-patches CC: rdapp.gcc; kito.cheng; kito.cheng; Jeff Law Subject: Re: [PATCH] RISC-V: Teach liveness computation

[PATCH] RISC-V: Fix loop invariant check

As Robin suggested, remove gimple_uid check which is sufficient for our need. Tested on both RV32/RV64 no regression, ok for trunk ? gcc/ChangeLog: * config/riscv/riscv-vector-costs.cc (loop_invariant_op_p): Fix loop invariant check. --- gcc/config/riscv/riscv-vector-costs.cc | 2 +-

RE: [PATCH v3] RISC-V: Bugfix for doesn't honor no-signed-zeros option

Thanks Richard B for comments. > We don't really expect targets to do this. The small testcase above > is somewhat ill-formed with -fno-signed-zeros. Note there's no > -0.0 in pr30957-1.c so why does that one fail for you? Does > the -fvariable-expansion-in-unroller code maybe not trigger for

RE: [PATCH] i386: Fix recent testcase fail

> -Original Message- > From: Jiang, Haochen > Sent: Monday, January 8, 2024 4:41 PM > To: gcc-patches@gcc.gnu.org > Cc: Liu, Hongtao ; ubiz...@gmail.com > Subject: [PATCH] i386: Fix recent testcase fail > > After commit 01f4251b8775c832a92d55e2df57c9ac72eaceef, early break >

ping^3: [PATCH] diagnostics: Fix behavior of permerror options after diagnostic pop [PR111918]

Can I please ping this one again? It's 3 lines or so to fix the PR. Thanks! https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html On Tue, Dec 19, 2023 at 6:20 PM Lewis Hyatt wrote: > > Hello- > > May I please ping this one? Thanks... >

[PATCH] Resolve issue with Canadian build for x86_64-w64-mingw32 multilibs

From: trcrsired In the case of x86_64-w64-mingw32 gcc with multilibs, a conflict arises as both 64-bit and 32-bit DLLs attempt to copy into the bin/ directory. This discrepancy results in coverage issues. This commit aligns the Canadian build process for gcc targeting Windows with cross

Re: [PATCH v4] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.

This patch looks ok from myside. juzhe.zh...@rivai.ai From: Jun Sha (Joshua) Date: 2024-01-03 14:08 To: gcc-patches CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw; christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu Subject: [PATCH v4] RISC-V: Adds the

Re: [PATCH v8 2/2] RISC-V: Add crypto vector api-testing cases.

LGTM. juzhe.zh...@rivai.ai From: Feng Wang Date: 2024-01-08 17:12 To: gcc-patches CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang Subject: [PATCH v8 2/2] RISC-V: Add crypto vector api-testing cases. Patch v8: Resubmit after fix the rtl-checking issue. Passed all the riscv regression

Re: [PATCH v7 1/2] RISC-V: Add crypto vector builtin function.

LGTM. juzhe.zh...@rivai.ai From: Feng Wang Date: 2024-01-08 17:12 To: gcc-patches CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang Subject: [PATCH v7 1/2] RISC-V: Add crypto vector builtin function. Patch v7:Resubmit after fix trl-checking issue. Passed all the riscv regression test.

Re: [committed V3] libstdc++: Add Unicode-aware width estimation for std::format

On Mon, 8 Jan 2024 at 01:19, Jonathan Wakely wrote: > > I decided to push this now, not wait for the morning. > > This is mostly the same as V2, but adds to the contrib/unicode/README as > suggested by Lewis, and avoids a trailing whitespace character in the > generated header. > > Tested

Re: c++/modules: Emit definitions of ODR-used static members imported from modules [PR112899]

On 1/8/24 04:21, Iain Sandoe wrote: On 6 Jan 2024, at 22:30, Nathan Sidwell wrote: Richard Smith & I discussed whether we should use the module interface's capability of giving vague linkage entities a strong location. I didn't want to go messing with that, 'cos it was changing yet more

[committed] xfail dg-final "Sunk statements: 5" on hppa*64*-*-*

Tested on hppa64-hp-hpux11.11. Committed to trunk. Dave --- xfail dg-final "Sunk statements: 5" on hppa*64*-*-* 2024-01-08 John David Anglin gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/ssa-sink-18.c: xfail dg-final "Sunk statements: 5" on hppa*64*-*-*. diff --git

[committed] Skip gfortran.dg/dec_math.f90 on hppa*-*-hpux*

Tested on hppa64-hp-hpux11.11. Committed to trunk. Dave --- Skip gfortran.dg/dec_math.f90 on hppa hppa*-*-hpux* doesn't have any long double trig functions. 2024-01-08 John David Anglin gcc/testsuite/ChangeLog: * gfortran.dg/dec_math.f90: Skip on hppa*-*-hpux*. diff --git

[r14-7003 Regression] FAIL: gfortran.dg/power_8.f90 -O3 -g execution test on Linux/x86_64

On Linux/x86_64, b3cc5a1efead520bc977b4ba51f1328d01b3e516 is the first bad commit commit b3cc5a1efead520bc977b4ba51f1328d01b3e516 Author: Richard Biener Date: Fri Dec 15 10:32:29 2023 +0100 tree-optimization/113026 - avoid vector epilog in more cases caused FAIL:

Re: [PATCH][frontend]: don't ice with pragma NOVECTOR if loop in C has no condition [PR113267]

On Mon, 8 Jan 2024, Tamar Christina wrote: > Hi All, > > In C you can have loops without a condition, the original version of the patch > was rejecting the use of #pragma GCC novector, however during review it was > changed to not due this with the reason that we didn't want to give a compile >

Re: [Patch, fortran PR89645/99065 No IMPLICIT type error with: ASSOCIATE( X => function() )

Hi Paul, your patch looks already very impressive! Regarding the patch as is, I am still trying to grok it, even with your explanations at hand... While the testcase works as advertised, I noticed that it exhibits a runtime memleak that occurs for (likely) each case where the associate target

Re: [PATCH] Add a late-combine pass [PR106594]

On 1/8/24 12:11, Richard Sandiford wrote: Thanks. That led me to the following, which seems a bit more plausible than my first attempt. I'll test it on aarch64-linux-gnu and x86_64-linux-gnu. Does it look OK? It looks reasonable to me. I'm going to send another failure (ICE in

[committed] hppa: Fix bind_c_coms.f90 and bind_c_vars.f90 tests on hppa

Tested on hppa64-hp-hpux11.11. Committed to trunk. Dave --- hppa: Fix bind_c_coms.f90 and bind_c_vars.f90 tests on hppa Commit 6271dd98 changed the default from -fcommon to -fno-common. This silently changed the alignment of uninitialized BSS data on hppa where the alignment of common data

Re: [PATCH] match.pd: Convert {I, X}OR of two values ANDed with alien CSTs to PLUS [PR108477]

On Mon, Jan 8, 2024 at 5:57 PM Andrew Pinski wrote: > > On Mon, Jan 8, 2024 at 6:44 AM Uros Bizjak wrote: > > > > Instead of converting XOR or PLUS of two values, ANDed with two constants > > that > > have no bits in common, to IOR expression, convert IOR or XOR of said two > > ANDed values to

Re: [Patch] GCN: Add pre-initial support for gfx1100

Hi! On 2024-01-08T15:30:06+0100, Tobias Burnus wrote: > Andrew Stubbs wrote: >> I know there will be things that need fixing for >> both experimental architectures. > > Indeed. [...] ..., like, making it even build? ;-P >> P.S. Apologies, but I think my commits today conflict a little; you >>

Re: [PATCH] Add a late-combine pass [PR106594]

Jeff Law writes: > On 1/8/24 09:59, Richard Sandiford wrote: >> This is a bit of a hopeful stab, but is the problem that recog_data still >> had the previous contents of insn 3674, and so extract_insn_cached wrongly >> thought that it doesn't need to do anything? If so, does something like: >>

[committed] steering.html: Update my affiliation

diff --git a/htdocs/steering.html b/htdocs/steering.html index 95d6a4a8..6039a503 100644 --- a/htdocs/steering.html +++ b/htdocs/steering.html @@ -36,7 +36,7 @@ place to reach them is the gcc mailing list. Jason Merrill (Red Hat) David Miller (Red Hat) Toon Moene (Koninklijk Nederlands

[committed] MAINTAINERS: Update my email address

* MAINTAINERS: Update my email address. diff --git a/MAINTAINERS b/MAINTAINERS index fe5d95ae970..882694cc47d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -34,7 +34,7 @@ Jeff Law Michael Meissner Jason Merrill

[wwwdocs] gcc-14/changes.html: OpenMP - improve wording

The attached patch does a tiny updated to the OpenMP features (AMD GCN now also has an optimized memcpy_rect not only nvptx), but the main change is some shifting around to make it more consistent and better readable. I intend to commit this relatively soon; like always, comments and

[PATCH] c++: non-dep array list-init w/ non-triv dtor [PR109899]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13/12? -- >8 -- The get_target_expr call added in r12-7069-g119cea98f66476 causes us for the below testcase to call build_vec_delete in a template context, which builds a templated destructor call and checks

Re: [PATCH] btf: print string position as comment for validation and testing purposes.

Thanks! Committed. David Faust writes: > Hi Cupertino, > > On 1/8/24 02:55, Cupertino Miranda wrote: >> Hi everyone, >> >> This patch adds a comment to the BTF strings regarding their position >> within the section. This is useful for assembly inspection purposes. >> >> Regards, >> Cupertino

Re: [PATCH] bpf: Correct BTF for kernel_helper attributed decls.

Thanks! Committed. David Faust writes: > Hi Cupetino, > > On 1/8/24 03:05, Cupertino Miranda wrote: >> Hi everyone, >> >> This patch address the problem reported in: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225 >> >> Looking forward to your review. > > LGTM, thanks. Please apply. >

Re: [PATCH] OpenMP: Support accelerated 2D/3D memory copies for AMD GCN

On Thu, 21 Dec 2023 17:05:18 +0100 Tobias Burnus wrote: > I think it makes sense to split this patch into two parts: > > * The libgomp/plugin/plugin-gcn.c – which is independent and would > already used by omp_memcpy_rect. I will commit this version in a moment. I needed to add the

[PATCH][GCC][Arm] Define __ARM_FEATURE_BF16 when +bf16 feature is enabled

Hi, Arm GCC backend does not define __ARM_FEATURE_BF16 when +bf16 is specified (via -march option, or target pragma) whereas it is supposed to be tested before including arm_bf16.h (as specified in ACLE document: https://arm-software.github.io/acle/main/acle.html#arm_bf16h). gcc/ChangeLog:

Re: [PATCH] bpf: Correct BTF for kernel_helper attributed decls.

Hi Cupetino, On 1/8/24 03:05, Cupertino Miranda wrote: > Hi everyone, > > This patch address the problem reported in: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225 > > Looking forward to your review. LGTM, thanks. Please apply. > > Cheers, > Cupertino > > > This patch fix a problem

Re: [PATCH] Add a late-combine pass [PR106594]

On 1/8/24 09:59, Richard Sandiford wrote: This is a bit of a hopeful stab, but is the problem that recog_data still had the previous contents of insn 3674, and so extract_insn_cached wrongly thought that it doesn't need to do anything? If so, does something like: diff --git a/gcc/recog.cc

Re: [PATCH] btf: print string position as comment for validation and testing purposes.

Hi Cupertino, On 1/8/24 02:55, Cupertino Miranda wrote: > Hi everyone, > > This patch adds a comment to the BTF strings regarding their position > within the section. This is useful for assembly inspection purposes. > > Regards, > Cupertino > > When using -dA, this function was only printing

Re: [PATCH] c++/modules: Prevent overwriting arguments for duplicates [PR112588]

On Mon, 8 Jan 2024, Nathaniel Shead wrote: > On Sat, Jan 06, 2024 at 05:32:37PM -0500, Nathan Sidwell wrote: > > I;m not sure about this, there was clearly a reason I did it the way it is, > > but perhaps that reasoning became obsolete -- something about an existing > > declaration and reading in

Re: [PATCH] match.pd: Convert {I, X}OR of two values ANDed with alien CSTs to PLUS [PR108477]

On 1/8/24 09:57, Andrew Pinski wrote: On Mon, Jan 8, 2024 at 6:44 AM Uros Bizjak wrote: Instead of converting XOR or PLUS of two values, ANDed with two constants that have no bits in common, to IOR expression, convert IOR or XOR of said two ANDed values to PLUS expression. I think this

Re: [PATCH] Add a late-combine pass [PR106594]

Jeff Law writes: > On 1/8/24 04:52, Richard Sandiford wrote: >> Jeff Law writes: >>> The other issue that's been in the back of my mind is costing. But I >>> think the model here is combine without regards to cost. >> >> No, it does take costing into account. For size, it's the usual >> "sum

Re: breakage with: [committed] libstdc++: Implement P2909R4 ("Dude, where's my char?") for C++20

On Mon, 8 Jan 2024 at 16:25, Hans-Peter Nilsson wrote: > > (Sorry, never a bringer of good news...) Regarding this bit ... even if you're reporting something I've broken, I like to see it as an incremental step towards better portability, so it's always good news ;-)

Re: [PATCH] match.pd: Convert {I, X}OR of two values ANDed with alien CSTs to PLUS [PR108477]

On Mon, Jan 8, 2024 at 6:44 AM Uros Bizjak wrote: > > Instead of converting XOR or PLUS of two values, ANDed with two constants that > have no bits in common, to IOR expression, convert IOR or XOR of said two > ANDed values to PLUS expression. I think this only helps targets which have leal like

Re: breakage with: [committed] libstdc++: Implement P2909R4 ("Dude, where's my char?") for C++20

On Mon, 8 Jan 2024 at 16:28, Hans-Peter Nilsson wrote: > > > From: Hans-Peter Nilsson > > Date: Mon, 8 Jan 2024 17:24:35 +0100 > > > For some reason, this (r14-6990-g74a0dab18292be) breaks a > > build of (newlib targets) at least cris-elf and arm-eabi: > > ...aaand, just now fixed in

Re: [PATCH] RISC-V: Teach liveness computation loop invariant shift amount[Dynamic LMUL]

> > +  if (is_gimple_min_invariant (op)) > > +    return true; > > +  if (SSA_NAME_IS_DEFAULT_DEF (op) > > +  || !flow_bb_inside_loop_p (loop, gimple_bb (SSA_NAME_DEF_STMT > (op > > +    return true; > > +  return gimple_uid (SSA_NAME_DEF_STMT (op)) & 1; > > +}

Re: [PATCH v3 2/3] libatomic: Enable LSE128 128-bit atomics for armv9.4-a

Hi Richard, >> Benchmarking showed that LSE and LSE2 RMW atomics have similar performance >> once >> the atomic is acquire, release or both. Given there is already a significant >> overhead due >> to the function call, PLT indirection and argument setup, it doesn't make >> sense to add >>

Re: breakage with: [committed] libstdc++: Implement P2909R4 ("Dude, where's my char?") for C++20

> From: Hans-Peter Nilsson > Date: Mon, 8 Jan 2024 17:24:35 +0100 > For some reason, this (r14-6990-g74a0dab18292be) breaks a > build of (newlib targets) at least cris-elf and arm-eabi: ...aaand, just now fixed in r14-7007-geb846114ed7c49. (Thanks!) brgds, H-P

breakage with: [committed] libstdc++: Implement P2909R4 ("Dude, where's my char?") for C++20

(Sorry, never a bringer of good news...) > From: Jonathan Wakely > Date: Mon, 8 Jan 2024 01:15:50 + > Tested x86_64-linux and aarch64-linux. Pushed to trunk. > > -- >8 -- > > This change ensures that char and wchar_t arguments are formatted > consistently when using integer presentation

Re: [PATCH] Add a late-combine pass [PR106594]

On 1/8/24 04:52, Richard Sandiford wrote: Jeff Law writes: The other issue that's been in the back of my mind is costing. But I think the model here is combine without regards to cost. No, it does take costing into account. For size, it's the usual "sum up the before and after insn

[committed] libstdc++: Remove std::__unicode::__null_sentinel

Tested x86_64-linux, pushed to trunk. -- >8 -- The name __null_sentinel is defined as a macro by newlib, so we can't use it as an identifier. That variable is not actually used by libstdc++, it was added because P2728R6 proposes std::uc::null_sentinel. Since we don't need it and it breaks

[libatomic PATCH] Fix testsuite regressions on ARM [raspberry pi].

Bootstrapping GCC on arm-linux-gnueabihf with --with-arch=armv6 currently has a large number of FAILs in libatomic (regressions since last time I attempted this). The failure mode is related to IFUNC handling with the file tas_8_2_.o containing an unresolved reference to the function

Re: [RFA] [V3] new pass for sign/zero extension elimination

Jeff Law writes: >>> + >>> +/* Initialization of the ext-dce pass. Primarily this means >>> + setting up the various bitmaps we utilize. */ >>> + >>> +static void >>> +ext_dce_init (void) >>> +{ >>> + >> >> Nit: excess blank line. > Various nits have been fixed. I think those are all mine.

Re: [PATCH v3 1/3] libatomic: atomic_16.S: Improve ENTRY, END and ALIAS macro interface

Victor Do Nascimento writes: > On 1/5/24 11:10, Richard Sandiford wrote: >> Victor Do Nascimento writes: >>> The introduction of further architectural-feature dependent ifuncs >>> for AArch64 makes hard-coding ifunc `_i' suffixes to functions >>> cumbersome to work with. It is awkward to

Re: [PATCH v2] c++/modules: Differentiate extern templates and TYPE_DECL_SUPPRESS_DEBUG [PR112820]

On Mon, 8 Jan 2024, Nathaniel Shead wrote: > On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote: > > On Sun, 3 Dec 2023, Nathaniel Shead wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > > > -- >8 -- > > > > > > The TYPE_DECL_SUPPRESS_DEBUG

[PATCH] match.pd: Convert {I, X}OR of two values ANDed with alien CSTs to PLUS [PR108477]

Instead of converting XOR or PLUS of two values, ANDed with two constants that have no bits in common, to IOR expression, convert IOR or XOR of said two ANDed values to PLUS expression. If we consider the following testcase: --cut here-- unsigned int foo (unsigned int a, unsigned int b) {

Re: [PATCH v3 2/3] libatomic: Enable LSE128 128-bit atomics for armv9.4-a

Wilco Dijkstra writes: > Hi, > >>> Is there no benefit to using SWPPL for RELEASE here? Similarly for the >>> others. >> >> We started off implementing all possible memory orderings available. >> Wilco saw value in merging less restricted orderings into more >> restricted ones - mainly to reduce

RE: [PATCH 2/2] arm: Add cortex-m52 doc

> -Original Message- > From: Chung-Ju Wu > Sent: Monday, January 8, 2024 6:17 AM > To: gcc-patches ; Kyrylo Tkachov > ; Richard Earnshaw > Cc: jason...@anshingtek.com.tw > Subject: [PATCH 2/2] arm: Add cortex-m52 doc > > Hi, > > This is the patch to add cortex-m52 in the Arm-related

RE: [PATCH 1/2] arm: Add cortex-m52 core

Hi jasonwucj, > -Original Message- > From: Chung-Ju Wu > Sent: Monday, January 8, 2024 6:16 AM > To: gcc-patches ; Kyrylo Tkachov > ; Richard Earnshaw > Cc: jason...@anshingtek.com.tw > Subject: [PATCH 1/2] arm: Add cortex-m52 core > > Hi, > > Recently, Arm announced the Cortex-M52,

Re: [Patch] GCN: Add pre-initial support for gfx1100

Hi Andrew, Andrew Stubbs wrote:    OK for mainline ? This looks fine to me. I know there will be things that need fixing for both experimental architectures. Indeed. I tried to be a bit more verbose also to avoid too high expectations by occasional gcc-patches@ readers. P.S. Apologies,

RE: [PATCH]middle-end: check if target can do extract first for early breaks [PR113199]

> -Original Message- > From: Richard Biener > Sent: Monday, January 8, 2024 12:48 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: Re: [PATCH]middle-end: check if target can do extract first for > early breaks > [PR113199] > > On Tue, 2 Jan

RE: [PATCH]middle-end: maintain LCSSA form when peeled vector iterations have virtual operands

> -Original Message- > From: Richard Biener > Sent: Monday, January 8, 2024 12:38 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: Re: [PATCH]middle-end: maintain LCSSA form when peeled vector > iterations have virtual operands > > On Fri, 29

Re: [PATCH] Clarify -mmovbe documentation

On Mon, Jan 8, 2024 at 10:56 AM Richard Biener wrote: > > It was noticed that -mmovbe doesn't use movbe for __builtin_bswap{32,64} > when not optimizing. The follownig adjusts the documentation to > say it will be used for optimizing and applies to all byte swaps, > not just those carried out

[PATCH 5/5] RISC-V: Document the syntax of -march

--- gcc/doc/invoke.texi | 16 1 file changed, 16 insertions(+) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 68d1f364ac0..81ee7ac758a 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -30037,6 +30037,22 @@ Generate code for given RISC-V ISA (e.g.@:

[PATCH 4/5] RISC-V: Update testsuite due to -march string relaxation

We has relaxed -march string, it no longer require canonical order, so we need update some of those testcase. gcc/testsuite/ChangeLog: * gcc.target/riscv/arch-23.c: Update test. * gcc.target/riscv/arch-27.c: Ditto. * gcc.target/riscv/arch-28.c: Ditto. *

[PATCH 3/5] RISC-V: Remove unused function in riscv_subset_list [NFC]

gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_subset_list::parse_std_ext): Remove. (riscv_subset_list::parse_multiletter_ext): Remove. * config/riscv/riscv-subset.h (riscv_subset_list::parse_std_ext): Remove.

[PATCH 2/5] RISC-V: Relax the -march string for accept any order

-march was require canonical order before, however it's not easy for most user when we have so many extension, so this patch is relax the constraint, -march accept the ISA string in any order, it only has few requirement: 1. Must start with rv[32|64][e|i|g]. 2. Multi-letter and single letter

[PATCH 1/5] RISC-V: Extract part parsing base ISA logic into a standalone function [NFC]

Minor refactor, preparation for further change. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_subset_list::parse_base_ext): New. (riscv_subset_list::parse): Extract part of logic into riscv_subset_list::parse_base_ext. *

[PATCH 0/5] RISC-V: Relax the -march string for accept any order

Do you know how to build a ISA string with following extension? - g - c - zba - zbs - svnapot - zve64d - zvl128b Don't trial and error with your gcc and don't read RISC-V ISA spec! OK, I believe it's impossible for most people, even I work for RISC-V so many years, I remember most of the rule

RE: [PATCH]middle-end: rejects loops with nonlinear inductions and early breaks [PR113163]

> -Original Message- > From: Richard Biener > Sent: Monday, January 8, 2024 12:07 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com > Subject: Re: [PATCH]middle-end: rejects loops with nonlinear inductions and > early > breaks [PR113163] > > On Fri, 29

RE: [PATCH] tree-optimization/113026 - avoid vector epilog in more cases

> -Original Message- > From: Richard Biener > Sent: Monday, January 8, 2024 11:29 AM > To: gcc-patches@gcc.gnu.org > Cc: Tamar Christina > Subject: [PATCH] tree-optimization/113026 - avoid vector epilog in more cases > > The following avoids creating a niter peeling epilog more

Re: [PATCH v4] aarch64: SVE/NEON Bridging intrinsics

On Mon, Dec 11, 2023 at 03:13:03PM +, Richard Ball wrote: > ACLE has added intrinsics to bridge between SVE and Neon. > > The NEON_SVE Bridge adds intrinsics that allow conversions between NEON and > SVE vectors. > > This patch adds support to GCC for the following 3 intrinsics: >

[PATCH v5 1/1] RISC-V: Add support for XCVbi extension in CV32E40P

Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md Contributors: Mary Bennett Nandni Jamnadas Pietra Ferreira Charlie Keaney Jessica Mills Craig Blackmore Simon Cook Jeremy Bennett Helene Chelin gcc/ChangeLog: *

[PATCH v5 0/1] RISC-V: Support CORE-V XCVBI extension

Thank you for reviewing my patches and merging XCVelw. This patch series presents the comprehensive implementation of the BI extension for CORE-V. Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to ensure its correctness and compatibility with the existing codebase.

Re: [PATCH v3 2/3] libatomic: Enable LSE128 128-bit atomics for armv9.4-a

Hi, >> Is there no benefit to using SWPPL for RELEASE here?  Similarly for the >> others. > > We started off implementing all possible memory orderings available. > Wilco saw value in merging less restricted orderings into more > restricted ones - mainly to reduce codesize in less frequently

Re: Add -falign-all-functions

On Thu, 4 Jan 2024, Jan Hubicka wrote: > Hi, > this patch adds new option -falign-all-functions which works like > -falign-functions, but applies to all functions including those in cold > regions. As discussed in the PR log, this is needed for atomically > patching function entries in the

[PATCH][frontend]: don't ice with pragma NOVECTOR if loop in C has no condition [PR113267]

Hi All, In C you can have loops without a condition, the original version of the patch was rejecting the use of #pragma GCC novector, however during review it was changed to not due this with the reason that we didn't want to give a compile error with such cases. However because annotations seem

Re: [PATCH] lower-bitint: Fix up lowering of huge _BitInt 0 PHI args [PR113120]

On Thu, 4 Jan 2024, Jakub Jelinek wrote: > Hi! > > The PHI argument expansion of INTEGER_CSTs where bitint_min_cst_precision > returns significantly smaller precision than the PHI result precision is > optimized by loading the much smaller constant (if any) from memory and > then either setting

Re: [PATCH] lower-bitint: Punt .*_OVERFLOW optimization if cast from IMAGPART_EXPR appears before REALPART_EXPR [PR113119]

On Thu, 4 Jan 2024, Jakub Jelinek wrote: > Hi! > > _BitInt lowering for .{ADD,SUB,MUL}_OVERFLOW calls which have both > REALPART_EXPR and IMAGPART_EXPR used and have a cast from the IMAGPART_EXPR > to a boolean or normal integral type lowers them at the point of > the REALPART_EXPR statement

Re: [PATCH]middle-end: check if target can do extract first for early breaks [PR113199]

On Tue, 2 Jan 2024, Tamar Christina wrote: > Hi All, > > I was generating the vector reverse mask without checking if the target > actually supported such an operation. > > It also seems like more targets implement VEC_EXTRACT than permute on mask > registers. > > So this adds a check for

Re: [PATCH]middle-end: maintain LCSSA form when peeled vector iterations have virtual operands

On Fri, 29 Dec 2023, Tamar Christina wrote: > Hi All, > > This patch fixes several interconnected issues. > > 1. When picking an exit we wanted to check for niter_desc.may_be_zero not > true. >i.e. we want to pick an exit which we know will iterate at least once. >However

Re: [PATCH v3 1/3] libatomic: atomic_16.S: Improve ENTRY, END and ALIAS macro interface

On 1/5/24 11:10, Richard Sandiford wrote: Victor Do Nascimento writes: The introduction of further architectural-feature dependent ifuncs for AArch64 makes hard-coding ifunc `_i' suffixes to functions cumbersome to work with. It is awkward to remember which ifunc maps onto which arch

Re: [PATCH]middle-end: Fix dominators updates when peeling with multiple exits [PR113144]

On Fri, 29 Dec 2023, Tamar Christina wrote: > Hi All, > > Only trying to update certain dominators doesn't seem to work very well > because as the loop gets versioned, peeled, or skip_vector then we end up with > very complicated control flow. This means that the final merge blocks for the >

Re: [PATCH]middle-end: rejects loops with nonlinear inductions and early breaks [PR113163]

On Fri, 29 Dec 2023, Tamar Christina wrote: > Hi All, > > We can't support nonlinear inductions other than neg when vectorizing > early breaks and iteration count is known. > > For early break we currently require a peeled epilog but in these cases > we can't compute the remaining values. > >

Re: [PATCH v2] c++/modules: Differentiate extern templates and TYPE_DECL_SUPPRESS_DEBUG [PR112820]

On Mon, Jan 8, 2024 at 10:58 AM Nathaniel Shead wrote: > > On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote: > > On Sun, 3 Dec 2023, Nathaniel Shead wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > > > -- >8 -- > > > > > > The

Re: [PATCH] Add a late-combine pass [PR106594]

Jeff Law writes: > The other issue that's been in the back of my mind is costing. But I > think the model here is combine without regards to cost. No, it does take costing into account. For size, it's the usual "sum up the before and after insn costs and see which one is lower". For speed,

Re: [PATCH] strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100]

On Mon, Jan 8, 2024 at 3:35 AM Kewen.Lin wrote: > > Hi, > > As PR113100 shows, the unbiasing introduced by r14-6737 can > cause the scrubbing to overrun and screw some critical data > on stack like saved toc base consequently cause segfault on > Power. > > By checking PR112917, IMHO we should

Re: [PATCH] sparc: Char arrays are 64-bit aligned on SPARC

On 2024-01-08 10:20, Eric Botcazou wrote: pr88077 fails on SPARC since char HeaderStr[1] in pr88077_1.c and long HeaderStr in pr88077_0.c differs in alignment. warning: alignment 4 of normal symbol `HeaderStr' in c_lto_pr88077_0.o is smaller than 8 used by the common definition in

Re: [PATCH] gimplify: Fix ICE in recalculate_side_effects [PR113228]

On Sat, 6 Jan 2024, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs during regimplificatgion since the addition of > (convert (eqne zero_one_valued_p@0 INTEGER_CST@1)) > simplification. That simplification is novel in the sense that in > gimplify_expr it can turn an expression

[PATCH] tree-optimization/113026 - avoid vector epilog in more cases

The following avoids creating a niter peeling epilog more consistently, matching what peeling later uses for the skip_vector condition, in particular when versioning is required which then also ensures the vector loop is entered unless the epilog is vectorized. This should ideally match

[PATCH] btf: print string position as comment for validation and testing purposes.

Hi everyone, This patch adds a comment to the BTF strings regarding their position within the section. This is useful for assembly inspection purposes. Regards, Cupertino When using -dA, this function was only printing as comment btf_string or btf_aux_string. This patch changes the comment to

[PATCH] bpf: Correct BTF for kernel_helper attributed decls.

Hi everyone, This patch address the problem reported in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225 Looking forward to your review. Cheers, Cupertino This patch fix a problem with kernel_helper attribute BTF information, which incorrectly generates BTF_KIND_FUNC entry. This BTF entry

Re: [PATCH v3] RISC-V: Bugfix for doesn't honor no-signed-zeros option

On Tue, Jan 2, 2024 at 2:37 PM wrote: > > From: Pan Li > > According to the sematics of no-signed-zeros option, the backend > like RISC-V should treat the minus zero -0.0f as plus zero 0.0f. > > Consider below example with option -fno-signed-zeros. > > void > test (float *a) > { > *a = -0.0; >

  1   2   >