Re: [pushed] analyzer: fix ICE in text art strings support

On Fri, 25 Aug 2023 at 18:15, David Malcolm via Gcc-patches wrote: > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > Pushed to trunk as r14-3481-g99a3fcb8ff0bf2. Hi David, It seems the new tests FAIL on arm for LTO bootstrap config:

[PATCH] doc: Add fpatchable-function-entry to Option-Summary page[PR110983]

The -fpatchable-function-entry is missing in both the web doc [1] and the man page's "Option Summary" section. This patch is to add it. [1]: https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html --- gcc/doc/invoke.texi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Bind RTL to a TREE expr (Re: [Bug target/111166])

Hi All! "rguenth at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66 ... > > > At RTL expansion time we store to D.2865 where it's DECL_RTL is r82:TI so > we can hardly fix it there. Only a later pass could figure each of the > insns fully define the reg. > >

Re: [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

On Tue, Aug 29, 2023 at 12:32 AM Eric Feng wrote: > > Hi Dave, > > Thanks for the feedback. I've addressed the changes you mentioned in > addition to adding more test cases. I've also taken this chance to > split the test files according to known function subclasses, as you previously >

[PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

Hi Dave, Thanks for the feedback. I've addressed the changes you mentioned in addition to adding more test cases. I've also taken this chance to split the test files according to known function subclasses, as you previously suggested. Since there were also some changes to the core analyzer,

Re: [PATCH] RISC-V: Refactor and clean expand_cond_len_{unop,binop,ternop}

Here is the V3 patch fix the comments, thanks. https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628650.html -- Best, Lehua

Re: [PATCH V2] RISC-V: Refactor and clean expand_cond_len_{unop, binop, ternop}

Invalid this patch, please see V3. Sorry for this. On 2023/8/29 11:43, Lehua Ding wrote: V2 changes: Address the comments from Robin. Hi, This patch refactors the codes of expand_cond_len_{unop,binop,ternop}. Introduces a new unified function expand_cond_len_op to do the main thing. The

[PATCH V3] RISC-V: Refactor and clean expand_cond_len_{unop, binop, ternop}

V3 changes: Address the comments from Robin. Hi, This patch refactors the codes of expand_cond_len_{unop,binop,ternop}. Introduces a new unified function expand_cond_len_op to do the main thing. The expand_cond_len_{unop,binop,ternop} functions only care about how to pass the operands to the

[PATCH V2] RISC-V: Refactor and clean expand_cond_len_{unop, binop, ternop}

V2 changes: Address the comments from Robin. Hi, This patch refactors the codes of expand_cond_len_{unop,binop,ternop}. Introduces a new unified function expand_cond_len_op to do the main thing. The expand_cond_len_{unop,binop,ternop} functions only care about how to pass the operands to the

[PATCH 0/1] RISC-V: Imply 'Zicsr' from 'Zcmt'

This is a subset of my patch set "RISC-V: Add stub support for existing extensions" for faster review. Since 'Zcmt' requires 'Zicsr' (and this is a bug unlike other changes in the patch set above), this small patch is splitted.

[PATCH 1/1] RISC-V: Imply 'Zicsr' from 'Zcmt'

From: Tsukasa OI As the specification states, the 'Zcmt' extension depends on the 'Zca' and 'Zicsr' extensions. This commit reflects this implication. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_implied_info): Add implication from 'Zcmt' to 'Zicsr'. ---

[PATCH v3 3/3] RISC-V: Add stub support for existing extensions (unprivileged)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on

[PATCH v3 2/3] RISC-V: Add stub support for existing extensions (vendor)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on

[PATCH v3 1/3] RISC-V: Add stub support for existing extensions (privileged)

From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the assembler). To avoid compilation errors on

[PATCH v3 0/3] RISC-V: Add stub support for existing extensions

PATCH v1: PATCH v2: Changes: v1 -> v2 (only in PATCH 3/3) == Removed: 'Zvkn' -> 'Zvknha' implication (not to cause test

[PATCH] RISC-V: Make arch-24.c to test "success" case

From: Tsukasa OI arch-24.c and arch-25.c are exactly the same and redundant. The author suspects that the original author intended to test two base ISAs (RV32I and RV64I) so this commit changes arch-24.c to test that RV32I+Zcf does not cause any errors. gcc/testsuite/ChangeLog: *

[PATCH v2] RISC-V: Make PR 102957 tests more comprehensive

From: Tsukasa OI Commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions and commit 6f709f79c915a ("[committed] [RISC-V] Fix expected diagnostic messages in testsuite") "fixed" test failures caused by that change (on pr102957.c,

[PATCH] RISC-V: Fix ASM check of vlmax_switch_vtype-16.c

Notice there is a failure: FAIL: gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-16.c -O2 scan-assembler-times vsetvli\\s+zero,\\s*zero 2 Fix "2" into "3", the assembly is correct and better. Committed. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-16.c:

Re: [PATCH v2 3/3] RISC-V: Add stub support for existing extensions (unprivileged)

On 2023/08/29 10:42, Jeff Law wrote: > > > On 8/14/23 00:09, Tsukasa OI wrote: >> From: Tsukasa OI >> >> After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown >> extensions") changed how do we handle unknown extensions, we have no >> guarantee that we can share the same

Re: [PATCH] RISC-V: Fix AVL/VL get ICE[VSETVL PASS]

Committed, thanks Kito. On 2023/8/29 10:46, Kito Cheng via Gcc-patches wrote: Assuming prev is vsetvli instruction is kind of a strong assumption, but it is guarded with gcc_assert, so it is a reasonable fix to me, LGTM :) On Tue, Aug 29, 2023 at 10:37 AM Juzhe-Zhong wrote: Fix bunch of ICE

[PATCH, rs6000] Call vector load/store with length expand only on 64-bit Power10 [PR96762]

Hi, This patch adds "TARGET_64BIT" check when calling vector load/store with length expand in expand_block_move. It matches the expand condition of "lxvl" and "stxvl" defined in vsx.md. This patch fixes the ICE occurred with the test case on 32-bit Power10. Bootstrapped and tested on

Re: [PATCH] RISC-V: Fix AVL/VL get ICE[VSETVL PASS]

Assuming prev is vsetvli instruction is kind of a strong assumption, but it is guarded with gcc_assert, so it is a reasonable fix to me, LGTM :) On Tue, Aug 29, 2023 at 10:37 AM Juzhe-Zhong wrote: > > Fix bunch of ICE in "vect" testsuite: > FAIL: gcc.dg/vect/vect-alias-check-16.c (internal

Re: Re: [PATCH 0/2] support cm.push cm.pop cm.popret in zcmp and resolve confilct with shrink-wrap-separate

> 1. flag_shrink_wrap_separate seems better than flag_shrink_wrap. (flag_)shrink_wrap_separate seems a sub optimization of (flag_)shrink_wrap, so I am fine if flag_shrink_wrap_separate is enough. > 2. to pass the zcmp testcases, i will add fno-shrink-wrap-separate option. OK

[COMMITTED V3] RISC-V: Fix error combine of pred_mov pattern

V3 change: Adjust the code format as Jeff suggests. This patch fix PR110943 which will produce some error code. This is because the error combine of some pred_mov pattern. Consider this code: ``` void foo9 (void *base, void *out, size_t vl) { int64_t scalar = *(int64_t*)(base + 100);

[PATCH] RISC-V: Fix AVL/VL get ICE[VSETVL PASS]

Fix bunch of ICE in "vect" testsuite: FAIL: gcc.dg/vect/vect-alias-check-16.c (internal compiler error: Segmentation fault) FAIL: gcc.dg/vect/vect-alias-check-16.c (test for excess errors) FAIL: gcc.dg/vect/vect-alias-check-16.c -flto -ffat-lto-objects (internal compiler error: Segmentation

Re: [RFC PATCH 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

On 2023/08/29 8:09, Hans-Peter Nilsson wrote: > On Mon, 28 Aug 2023, Jeff Law via Gcc-patches wrote: >> >> >> On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: >>> From: Tsukasa OI >>> >>> This built-in does not imply the 'Xgnuzihintpausestate' extension. >>> It does not change architectural

Re: [PATCH] RISC-V: Revive test case PR 102957

On 2023/08/29 7:01, Jeff Law wrote: > > > On 8/11/23 08:29, Tsukasa OI wrote: >> On 2023/08/11 23:15, Jeff Law wrote: > >>> >> >> Originally, it tested that a two letter extension ('Zb') is accepted by >> GCC (because the background of PR 102957 was GCC assumed multi-letter >> 'Z' extensions

Re: [PATCH 1/1] RISC-V: Make "prefetch.i" built-in usable

On 2023/08/29 6:20, Jeff Law wrote: > > > On 8/9/23 21:10, Tsukasa OI via Gcc-patches wrote: >> From: Tsukasa OI >> >> The "__builtin_riscv_zicbop_cbo_prefetchi" built-in function was terribly >> broken so that practically unusable.  It emitted "prefetch.i" but with no >> meaningful arguments.

Re: [RFC PATCH 1/2] RISC-V: __builtin_riscv_pause for all environment

On 2023/08/29 6:12, Jeff Law wrote: > > > On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: >> From: Tsukasa OI >> >> The "pause" RISC-V hint instruction requires the 'Zihintpause' extension >> (in the assembler).  However, GCC emits "pause" unconditionally, making >> an assembler error

Re: [PATCH 1/2] allow targets to check shrink-wrap-separate enabled or not

On 8/28/23 19:28, Fei Gao wrote: On 2023-08-29 06:54  Jeff Law wrote: On 8/28/23 01:47, Fei Gao wrote: no functional changes but allow targets to check shrink-wrap-separate enabled or not.     gcc/ChangeLog:   * shrink-wrap.cc (try_shrink_wrapping_separate):call    

Re: [PATCH] mklog: fix bugs of --append option

Committed the V2 patch, which additional fix some code format warning, thanks Jeff. On 2023/8/29 7:38, Jeff Law wrote: On 7/19/23 02:21, Lehua Ding wrote: Hi, This little patch fix two bugs of mklog.py with --append option. The first bug is that the regexp used is not accurate enough to

Re: [PATCH v2 3/3] RISC-V: Add stub support for existing extensions (unprivileged)

On 8/14/23 00:09, Tsukasa OI wrote: From: Tsukasa OI After commit c283c4774d1c ("RISC-V: Throw compilation error for unknown extensions") changed how do we handle unknown extensions, we have no guarantee that we can share the same architectural string with Binutils (specifically, the

Re: Re: [PATCH 1/2] allow targets to check shrink-wrap-separate enabled or not

On 2023-08-29 06:54  Jeff Law wrote: > > > >On 8/28/23 01:47, Fei Gao wrote: >> no functional changes but allow targets to check shrink-wrap-separate >> enabled or not. >> >>    gcc/ChangeLog: >> >>  * shrink-wrap.cc (try_shrink_wrapping_separate):call >>   

Re: [pushed][PATCH v2] LoongArch: Enable '-free' starting at -O2.

Pushed to r14-3533. 在 2023/8/28 下午5:21, Xi Ruoyao 写道: On Mon, 2023-08-28 at 11:46 +0800, Lulu Cheng wrote: v1 -> v2: 1. Modify Changelog information format. gcc/ChangeLog: * common/config/loongarch/loongarch-common.cc: Enable '-free' on O2 and above. *

Re: Re: [PATCH V4] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

>> Juzhe mentioned he doesn't want to commit this before >> all/most bugs are addresses anyway, right? Yes. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-08-28 22:27 To: Kito Cheng; Juzhe-Zhong CC: rdapp.gcc; gcc-patches; kito.cheng Subject: Re: [PATCH V4] RISC-V: Enable vec_int testsuite

Re: [PATCH] mklog: fix bugs of --append option

On 7/19/23 02:21, Lehua Ding wrote: Hi, This little patch fix two bugs of mklog.py with --append option. The first bug is that the regexp used is not accurate enough to determine the top of diff area. The second bug is that if `---` is not a true start, it needs to be added back to the patch

Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

On 8/24/23 08:06, Robin Dapp via Gcc-patches wrote: Ping. I refined the code and some comments a bit and added a test case. My question in general would still be: Is this something we want given that we potentially move some of combine's work a bit towards the front of the RTL pipeline?

[PATCH v2] c++: tweaks for explicit conversion fns diagnostic

On Fri, Aug 25, 2023 at 08:34:37PM -0400, Jason Merrill wrote: > On 8/25/23 19:37, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > > > 1) When saying that a conversion is erroneous because it would use > > an explicit constructor, it

Re: [PATCH] [tree-optimization/110279] swap operands in reassoc to reduce cross backedge FMA

On 8/28/23 02:17, Di Zhao OS via Gcc-patches wrote: This patch tries to fix the 2% regression in 510.parest_r on ampere1 in the tracker. (Previous discussion is here: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624893.html) 1. Add testcases for the problem. For an op list in the form

Re: [RFC PATCH 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

On 8/28/23 17:09, Hans-Peter Nilsson wrote: On Mon, 28 Aug 2023, Jeff Law via Gcc-patches wrote: On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: From: Tsukasa OI This built-in does not imply the 'Xgnuzihintpausestate' extension. It does not change architectural state (because all

Re: [RFC PATCH 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

On Mon, 28 Aug 2023, Jeff Law via Gcc-patches wrote: > > > On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: > > From: Tsukasa OI > > > > This built-in does not imply the 'Xgnuzihintpausestate' extension. > > It does not change architectural state (because all HINTs are prohibited > > from

Re: [PATCH] c++: CWG 2359, wrong copy-init with designated init [PR91319]

On Mon, Aug 28, 2023 at 06:27:26PM -0400, Jason Merrill wrote: > On 8/25/23 12:44, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > > > This CWG clarifies that designated initializer support > > direct-initialization. > > Just be careful

Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]

On 8/24/23 09:31, Patrick Palka wrote: On Wed, 23 Aug 2023, Jason Merrill wrote: On 8/21/23 21:51, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like a reasonable approach? I didn't observe any compile time/memory impact of this change. -- >8 -- As

Re: [PATCH 1/2] allow targets to check shrink-wrap-separate enabled or not

On 8/28/23 01:47, Fei Gao wrote: no functional changes but allow targets to check shrink-wrap-separate enabled or not. gcc/ChangeLog: * shrink-wrap.cc (try_shrink_wrapping_separate):call use_shrink_wrapping_separate. (use_shrink_wrapping_separate): wrap the

Re: [PATCH V3] riscv: generate builtin macro for compilation with strict alignment:

On 8/15/23 12:29, Edwin Lu wrote: This patch is a modification of https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610115.html following the discussion on https://github.com/riscv-non-isa/riscv-c-api-doc/issues/32 Distinguish between explicit -mstrict-align and cpu tune param for

Re: [PATCH 1/2] allow target to check shrink-wrap-separate enabled or not

On 6/25/23 20:29, Fei Gao wrote: hi Jeff Please see my earlier reply here. https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg310656.html Maybe you scrolled past it in so many emails:) Oh, so the issue isn't really the set of components being wrapped, but the way in which we save

Re: [PATCH] c++: use conversion_obstack_sentinel throughout

On 8/25/23 12:33, Patrick Palka wrote: Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- This replaces manual memory management via conversion_obstack_alloc(0) and obstack_free with the recently added conversion_obstack_sentinel, and also uses the

Re: [PATCH] c++: more dummy non_constant_p arg avoidance

On 8/25/23 13:41, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? This reduces calls to is_rvalue_constant_expression from cp_parser_constant_expression by 10% for stdc++.h. OK. -- >8 -- As a follow-up to Marek's r14-3088-ga263152643bbec, this patch makes

Re: [PATCH] c++: CWG 2359, wrong copy-init with designated init [PR91319]

On 8/25/23 12:44, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This CWG clarifies that designated initializer support direct-initialization. Just be careful what Note 2 in [dcl.init.aggr]/4.2 says: "If the initialization is by

Re: [PATCH 1/2] allow target to check shrink-wrap-separate enabled or not

On 6/25/23 20:29, Fei Gao wrote: hi Jeff Please see my earlier reply here. https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg310656.html Maybe you scrolled past it in so many emails:) It definitely got lost in my mountain of mail. jeff

Re: [PATCH] RISC-V: Revive test case PR 102957

On 8/11/23 08:29, Tsukasa OI wrote: On 2023/08/11 23:15, Jeff Law wrote: Originally, it tested that a two letter extension ('Zb') is accepted by GCC (because the background of PR 102957 was GCC assumed multi-letter 'Z' extensions are three letters or more). After rejecting unrecognized

Re: [PATCH] RISC-V: Add Types to Un-Typed Vector Instructions:

On 8/28/23 13:03, Edwin Lu wrote: Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates vector instructions to ensure that no insn is left without a type attribute. Creates a placeholder type "vector" for insns where a

Re: [PATCH V2] RISC-V: Fix error combine of pred_mov pattern

On 8/10/23 06:21, Lehua Ding wrote: +;; vle.v/vse.v,vmv.v.v +(define_insn_and_split "*pred_mov" + [(set (match_operand:V_VLS 0 "nonimmediate_operand""=vr,vr, vd, m,vr,vr") +(if_then_else:V_VLS + (unspec: +[(match_operand: 1

Re: [PATCH] RISC-V: Fix error combine of pred_mov pattern

On 8/11/23 10:30, Lehua Ding wrote: > But combine doesn't run at -O0.  So something is inconsistent.  I > certainly believe we need to avoid the mem->mem case, but that's > independent of combine and affects all optimization levels. This is an new bug when running all tests after fixing

Re: [PATCH 1/1] RISC-V: Make "prefetch.i" built-in usable

On 8/9/23 21:10, Tsukasa OI via Gcc-patches wrote: From: Tsukasa OI The "__builtin_riscv_zicbop_cbo_prefetchi" built-in function was terribly broken so that practically unusable. It emitted "prefetch.i" but with no meaningful arguments. Though incompatible, this commit completely changes

Re: [RFC PATCH 2/2] RISC-V: Fix documentation of __builtin_riscv_pause

On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: From: Tsukasa OI This built-in does not imply the 'Xgnuzihintpausestate' extension. It does not change architectural state (because all HINTs are prohibited from doing that). gcc/ChangeLog: * doc/extend.texi: Fix the description

Re: [RFC PATCH 1/2] RISC-V: __builtin_riscv_pause for all environment

On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote: From: Tsukasa OI The "pause" RISC-V hint instruction requires the 'Zihintpause' extension (in the assembler). However, GCC emits "pause" unconditionally, making an assembler error while compiling code with __builtin_riscv_pause while the

[PATCH] MATCH: Move `(x | y) & (~x ^ y)` over to use bitwise_inverted_equal_p

This moves the match pattern `(x | y) & (~x ^ y)` over to use bitwise_inverted_equal_p. This now also allows to optmize comparisons and also catches the missed `(~x | y) & (x ^ y)` transformation into `~x & y`. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog:

[PATCH ver 4] rs6000, add overloaded DFP quantize support

GCC maintainers: Version 4, additional define_insn name fix. Change Log fix for the UNSPEC_DQUAN. Retested patch on Power 10 LE. Version 3, fixed the built-in instance names. Missed removing the "n" the name. Added the tighter constraints on the predicates for the define_insn. Updated the

Re: [PATCH ver 3] rs6000, add overloaded DFP quantize support

On Mon, 2023-08-28 at 10:21 +0800, Kewen.Lin wrote: > Hi Carl, > > > > A testcase is added for the new built-in definitions. > > > > gcc/ChangeLog: > > * config/rs6000/dfp.md: New UNSPEC_DQUAN. > > Nit: (UNSPEC_DQUAN): New unspec. Fixed. > > > +(define_insn "dfp_dqua_" > > + [(set

[PATCH] Fix cond-bool-2.c on powerpc and other targets

This adds `--param logical-op-non-short-circuit=1` to the tescase so it becomes a target indepdendent testcase now. I filed PR 111217 as the variant of the testcase which fails indepdendently of the param. Committed as obvious after testing to make sure it passes on powerpc now.

Re: [PATCH] fortran: Restore interface to its previous state on error [PR48776]

Hi Mikael, On 8/27/23 21:22, Mikael Morin via Gcc-patches wrote: Hello, this fixes an old error-recovery bug. Tested on x86_64-pc-linux-gnu. OK for master? I have only a minor comment: +/* Free the leading members of the gfc_interface linked list given in INTR + up to the END element

[PATCH] RISC-V: Add Types to Un-Typed Vector Instructions:

Related Discussion: https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/ This patch updates vector instructions to ensure that no insn is left without a type attribute. Creates a placeholder type "vector" for insns where a type isn't clear Tested for

Re: [PATCH V4] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

On 8/28/23 08:27, Robin Dapp via Gcc-patches wrote: LGTM from my side, but I would like to wait Robin is ok too In principle I'm OK with it as well, realizing we will still need to fine-tune a lot here anyway. For now, IMHO it's good to have some additional test coverage in the vector

[April 2022 PING] cpp: new built-in __EXP_COUNTER__

On 2022-06-13 16:13, Kaz Kylheku wrote: > Pinging this item: > > https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593473.html > > Thanks.

[PATCH v2] aarch64: Fine-grained ldp and stp policies with test-cases.

This patch implements the following TODO in gcc/config/aarch64/aarch64.cc to provide the requested behaviour for handling ldp and stp: /* Allow the tuning structure to disable LDP instruction formation from combining instructions (e.g., in peephole2). TODO: Implement fine-grained

[RFC] > WIDE_INT_MAX_PREC support in wide-int

Hi! While the _BitInt series isn't committed yet, I had a quick look at lifting the current lowest limitation on maximum _BitInt precision, that wide_int can only support wide_int until WIDE_INT_MAX_PRECISION - 1. Note, other limits if that is lifted are INTEGER_CST currently using 3 unsigned

Re: [PATCH V4] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

> LGTM from my side, but I would like to wait Robin is ok too In principle I'm OK with it as well, realizing we will still need to fine-tune a lot here anyway. For now, IMHO it's good to have some additional test coverage in the vector space but we should not expect every test to be correct/a

Re: [PATCH V4] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

LGTM from my side, but I would like to wait Robin is ok too Juzhe-Zhong 於 2023年8月28日 週一，19:43寫道： > XPASS: gcc.dg/vect/no-scevccp-outer-12.c scan-tree-dump-times vect "OUTER > LOOP VECTORIZED." 1 > XPASS: gcc.dg/vect/no-scevccp-outer-16.c scan-tree-dump-times vect "OUTER > LOOP VECTORIZED." 1 >

[PATCH] libcpp, v2: Small incremental patch for P1854R4 [PR110341]

Hi! Sorry, testing revealed an unused uchar *outbuf; declaration breaking the build, here is the same patch with that one line removed, bootstrapped/regtested on x86_64-linux and i686-linux (on top of the earlier POR110341 patch). On Sat, Aug 26, 2023 at 01:11:06PM +0200, Jakub Jelinek via

[PATCH] c++, v2: Fix up mangling of function/block scope static structured bindings and emit abi tags [PR111069]

Hi! On Thu, Aug 24, 2023 at 06:39:10PM +0200, Jakub Jelinek via Gcc-patches wrote: > > Maybe do this in mangle_decomp, based on the actual mangling in process > > instead of this pseudo-mangling? > > Not sure that is possible, for 2 reasons: > 1) determine_local_discriminator otherwise works on

Re: Ping^^ [PATCH V5 2/2] Optimize '(X - N * M) / N' to 'X / N - M' if valid

On Wed, 23 Aug 2023, guojiufu wrote: > Hi, > > I would like to have a gentle ping... > > BR, > Jeff (Jiufu Guo) > > On 2023-08-07 10:45, guojiufu via Gcc-patches wrote: > > Hi, > > > > Gentle ping... > > > > On 2023-07-18 22:05, Jiufu Guo wrote: > >> Hi, > >> > >> Integer expression "(X - N

RE: [PATCH] RISC-V: Fix uninitialized probability for GIMPLE IR tests

Committed, thanks Kito. Pan -Original Message- From: Gcc-patches On Behalf Of Kito Cheng via Gcc-patches Sent: Monday, August 28, 2023 8:59 PM To: Juzhe-Zhong Cc: GCC Patches ; Kito Cheng Subject: Re: [PATCH] RISC-V: Fix uninitialized probability for GIMPLE IR tests LGTM

Re: [PATCH] RISC-V: Fix uninitialized probability for GIMPLE IR tests

LGTM Juzhe-Zhong 於 2023年8月28日 週一 19:40 寫道： > This patch fix unitialized probability in GIMPLE IR code tests: > FAIL: gcc.dg/vect/slp-reduc-10a.c (internal compiler error: in > compute_probabilities, at config/riscv/riscv-vsetvl.cc:4358) > FAIL: gcc.dg/vect/slp-reduc-10a.c (test for excess

Re: Re: [PATCH V3] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

Ok. It reduced some failures, and new report is updated on the commit log in V4: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628580.html juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-08-28 18:29 To: Juzhe-Zhong; gcc-patches CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw

[PATCH V4] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

XPASS: gcc.dg/vect/no-scevccp-outer-12.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED." 1 XPASS: gcc.dg/vect/no-scevccp-outer-16.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED." 1 XPASS: gcc.dg/vect/no-scevccp-outer-17.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED." 1 XPASS:

[PATCH] RISC-V: Fix uninitialized probability for GIMPLE IR tests

This patch fix unitialized probability in GIMPLE IR code tests: FAIL: gcc.dg/vect/slp-reduc-10a.c (internal compiler error: in compute_probabilities, at config/riscv/riscv-vsetvl.cc:4358) FAIL: gcc.dg/vect/slp-reduc-10a.c (test for excess errors) FAIL: gcc.dg/vect/slp-reduc-10a.c -flto

Re: [PATCH] RISC-V: Refactor and clean expand_cond_len_{unop,binop,ternop}

Hi Robin, Thanks for reviewing. Cleanup up here is good, right now it's not really an insn_type but indeed just the number of operands. My original idea was to have an insn type and a mostly unified expander that performs all necessary operations depending on the insn_type. Just to give an

Re: Re: [PATCH 0/2] support cm.push cm.pop cm.popret in zcmp and resolve confilct with shrink-wrap-separate

On 2023-08-28 17:27  Kito Cheng wrote: > >I would prefer to decouple the shrink-wrap part by checking >flag_shrink_wrap, I mean let disable zcmp code gen if flag_shrink_wrap >is true for now, and a follow up patch series with shrink-wrap.[cc|h] >changes? OK. some details to be confirmed by

Re: [PATCH] RISC-V: Refactor and clean expand_cond_len_{unop,binop,ternop}

Hi Lehua, thanks for starting with the refactoring. I have some minor comments. > +/* The value means the number of operands for insn_expander. */ > enum insn_type > { >RVV_MISC_OP = 1, >RVV_UNOP = 2, > - RVV_UNOP_M = RVV_UNOP + 2, > - RVV_UNOP_MU = RVV_UNOP + 2, > - RVV_UNOP_TU =

Re: [PATCH] c++: Implement C++ DR 2406 - [[fallthrough]] attribute and iteration statements

On Fri, 25 Aug 2023, Jakub Jelinek wrote: > Hi! > > The following patch implements > CWG 2406 - [[fallthrough]] attribute and iteration statements > The genericization of some loops leaves nothing at all or just a label > after a body of a loop, so if the loop is later followed by > case or

Re: [PATCH V3] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

On 8/28/23 12:16, Juzhe-Zhong wrote: > FAIL: gcc.dg/vect/bb-slp-10.c -flto -ffat-lto-objects scan-tree-dump slp2 > "unsupported unaligned access" > FAIL: gcc.dg/vect/bb-slp-10.c scan-tree-dump slp2 "unsupported unaligned > access" > XPASS: gcc.dg/vect/no-scevccp-outer-12.c scan-tree-dump-times

Re: Re: [PATCH V2] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

Ok. Add -Wno-psabi which reduce 5 FAILS. V3: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628572.html juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-08-28 16:22 To: Juzhe-Zhong; gcc-patches CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw Subject: Re: [PATCH V2] RISC-V: Enable

[PATCH V3] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

FAIL: gcc.dg/vect/bb-slp-10.c -flto -ffat-lto-objects scan-tree-dump slp2 "unsupported unaligned access" FAIL: gcc.dg/vect/bb-slp-10.c scan-tree-dump slp2 "unsupported unaligned access" XPASS: gcc.dg/vect/no-scevccp-outer-12.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED." 1 XPASS:

Re: [PATCH V2] RISC-V: Disable user vsetvl fusion into EMPTY or DIRTY (Polluted EMPTY) block

Committed, thanks Kito. On 2023/8/28 17:55, Kito Cheng via Gcc-patches wrote: LGTM, that's much clearer than v1 to me :) On Mon, Aug 28, 2023 at 5:54 PM Juzhe-Zhong wrote: This patch is fixing these bunch of ICE in "vect" testsuite: FAIL: gcc.dg/vect/no-scevccp-outer-2.c (internal compiler

Re: [PATCH V2] RISC-V: Disable user vsetvl fusion into EMPTY or DIRTY (Polluted EMPTY) block

LGTM, that's much clearer than v1 to me :) On Mon, Aug 28, 2023 at 5:54 PM Juzhe-Zhong wrote: > > This patch is fixing these bunch of ICE in "vect" testsuite: > FAIL: gcc.dg/vect/no-scevccp-outer-2.c (internal compiler error: in > anticipatable_occurrence_p, at config/riscv/riscv-vsetvl.cc:314)

Re: Re: [PATCH] RISC-V: Disable user vsetvl fusion into EMPTY block

Address comments: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628568.html juzhe.zh...@rivai.ai From: Kito Cheng Date: 2023-08-28 16:58 To: Robin Dapp CC: Juzhe-Zhong; gcc-patches; kito.cheng Subject: Re: [PATCH] RISC-V: Disable user vsetvl fusion into EMPTY block Is it possible to

[PATCH V2] RISC-V: Disable user vsetvl fusion into EMPTY or DIRTY (Polluted EMPTY) block

This patch is fixing these bunch of ICE in "vect" testsuite: FAIL: gcc.dg/vect/no-scevccp-outer-2.c (internal compiler error: in anticipatable_occurrence_p, at config/riscv/riscv-vsetvl.cc:314) FAIL: gcc.dg/vect/no-scevccp-outer-2.c (test for excess errors) FAIL: gcc.dg/vect/pr109025.c (internal

Re: [PATCH] alias-analyis: try to find ADDR_EXPR for SSA_NAME ptr

On Mon, Aug 28, 2023 at 11:35 AM Di Zhao OS via Gcc-patches wrote: > > This patch tries to improve alias-analysis between an SSA_NAME and > a declaration a little. For a case like: > > int array1[10], array2[10]; > ptr1 = array1 + x; > ptr2 = ptr1 + y; > > , *ptr2 should

[PATCH] alias-analyis: try to find ADDR_EXPR for SSA_NAME ptr

This patch tries to improve alias-analysis between an SSA_NAME and a declaration a little. For a case like: int array1[10], array2[10]; ptr1 = array1 + x; ptr2 = ptr1 + y; , *ptr2 should not alias with array2. If we can't disambiguate from points-to information, this

Re: [PATCH] s390: Fix builtins vec_rli and verll

Hi Stefan, do you really need to introduce a new flag for U64 given that the type of the builtin is unsigned long? Andreas On 8/21/23 17:56, Stefan Schulze Frielinghaus wrote: > The second argument of these builtins is an unsigned immediate. For > vec_rli the API allows immediates up to 64

Re: [PATCH 0/2] support cm.push cm.pop cm.popret in zcmp and resolve confilct with shrink-wrap-separate

I would prefer to decouple the shrink-wrap part by checking flag_shrink_wrap, I mean let disable zcmp code gen if flag_shrink_wrap is true for now, and a follow up patch series with shrink-wrap.[cc|h] changes? On Mon, Aug 28, 2023 at 3:48 PM Fei Gao wrote: > > The first is a helper patch to

Re: [PATCH] s390: Fix some builtin definitions

On 8/21/23 17:58, Stefan Schulze Frielinghaus wrote: > Bootstrapped and regtested on s390. Ok for mainline? > > gcc/ChangeLog: > > * config/s390/s390-builtins.def (s390_vec_signed_flt): Fix > builtin flag. > (s390_vec_unsigned_flt): Ditto. > (s390_vec_revb_flt): Ditto. >

Re: [PATCH v2] LoongArch: Enable '-free' starting at -O2.

On Mon, 2023-08-28 at 11:46 +0800, Lulu Cheng wrote: > v1 -> v2: > 1. Modify Changelog information format. > > gcc/ChangeLog: > > * common/config/loongarch/loongarch-common.cc: > Enable '-free' on O2 and above. > * doc/invoke.texi: Modify the description

Re: [PATCH-2, rs6000] Implement 32bit inline lrint [PR88558]

Hi Haochen, on 2023/8/25 14:44, HAO CHEN GUI wrote: > Hi, > This patch implements 32bit inline lrint by "fctiw". It depends on > the patch1 to do SImode move from FP register on P7. > > Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. > > Thanks > Gui Haochen > >

Re: [PATCH-1, rs6000] Enable SImode in FP register on P7 [PR88558]

Hi Haochen, on 2023/8/25 14:44, HAO CHEN GUI wrote: > Hi, > This patch enables SImode in FP register on P7. Instruction "fctiw" > stores its integer output in an FP register. So SImode in FP register > needs be enabled on P7 if we want support "fctiw" on P7. > It sounds reasonable to support

Re: Re: [PATCH] RISC-V: Disable user vsetvl fusion into EMPTY block

What about that? I guess I don't really know how to determine if a block is EMPTY? diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc index 682f795c8e1..784ab184c72 100644 --- a/gcc/config/riscv/riscv-vsetvl.cc +++ b/gcc/config/riscv/riscv-vsetvl.cc @@ -3282,6

Re: Re: [PATCH] RISC-V: Disable user vsetvl fusion into EMPTY block

No. we can't. My goal is to forbid this following situation: bb 2: EMPTY (no any vsetvl and rvv insn) bb 3: user vsetvl. We forbid user vsetvl (bb 3) be move to bb 2 in earliest fusion since user vsetvl has no side effects and we believe user vsetvl in bb 3 here is early enough. However, if

Patch ping^2 Re: [PATCH 0/12] GCC _BitInt support [PR102989]

Hi! On Mon, Aug 21, 2023 at 05:24:02PM +0200, Jakub Jelinek via Gcc-patches wrote: > Jakub Jelinek (12): > expr: Small optimization [PR102989] > lto-streamer-in: Adjust assert [PR102989] > phiopt: Fix phiopt ICE on vops [PR102989] > Middle-end _BitInt support [PR102989] > _BitInt

Re: [PATCH] RISC-V: Disable user vsetvl fusion into EMPTY block

Is it possible to skip that at the topper level like that? diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc index 682f795c8e1..654d25de593 100644 --- a/gcc/config/riscv/riscv-vsetvl.cc +++ b/gcc/config/riscv/riscv-vsetvl.cc @@ -3269,7 +3269,7 @@

  1   2   >