[GCC14 QUEUE PATCH] RISC-V: Fix RVV register order

From: Juzhe-Zhong Co-authored-by: kito-cheng Co-authored-by: kito-cheng This patch fixes the issue of incorrect reigster order of RVV. The new register order is coming from kito original RVV GCC implementation. Consider this case: void f (void *base,void *base2,void *out,size_t vl, int n) {

[GCC14 QUEUE PATCH] RISC-V: Fix RVV register order

From: Juzhe-Zhong This patch fixes the issue of incorrect reigster order of RVV. The new register order is coming from kito original RVV GCC implementation. Consider this case: void f (void *base,void *base2,void *out,size_t vl, int n) { vuint64m8_t bindex = __riscv_vle64_v_u64m8 (base + 100

Re: [PATCH][stage1] Remove conditionals around free()

On Fri, Mar 3, 2023 at 10:14 PM Jerry D via Fortran wrote: > I am certainly not a C++ expert but it seems to me this all begs for > automatic finalization where one would not have to invoke free at all. > I suspect the gfortran frontend is not designed for such things. +1 for RAII

Re: [PATCH] RISC-V: Optimize zbb ins sext.b and sext.h in rv64

Hi Juzhe, Thank you for your reply, I'm really doing some optimization work right now. I am very interested in the question you have raised, and I will take the time to try to optimize it. I hope I can communicate with you and learn from you more in the future. Thanks.

Re: [PATCH] vect: Check that vector factor is a compile-time constant

On Thu, 23 Mar 2023 16:18:20 PDT (-0700), jeffreya...@gmail.com wrote: On 3/17/23 10:57, Palmer Dabbelt wrote: I'm a little bit confused about what the proposal is here: is the idea to have a branch based on gcc-13 where we coordinate work before it lands on trunk, or a branch based on gcc-1

[PATCH] RISC-V: Optimize zbb ins sext.b and sext.h in rv64

Sounds like you are looking at redundant extension problem in RISC-V port. This is the issue I want to fix but I don't find the time to do that. My first impression is that we need to fix redundant extension in "ree" PASS. I am not sure. Base on you are looking at this kind of issues, would you mi

RISC-V: Optimize zbb ins sext.b and sext.h in rv64

Sounds like you are looking at redundant extension problem in RISC-V port. This is the issue I want to fix but I don't find the time to do that. My first impression is that we need to fix redundant extension in "ree" PASS. I am not sure. Base on you are looking at this kind of issues, would you mi

[PATCH] RISC-V: Optimize zbb ins sext.b and sext.h in rv64

This patch optimize the combine processing for sext.b/h in rv64. Please refer to the following test case, int sextb32(int x) { return (x << 24) >> 24; } The rtl expression is as follows, (insn 6 3 7 2 (set (reg:SI 138) (ashift:SI (subreg/s/u:SI (reg/v:DI 136 [ xD.2271 ]) 0) (co

[PATCH] RISC-V: Optimize load memory data in rv64

This patch optimize load one byte or halfword from memory in rv64. Please refer to the following test case for loading one byte. int sextb32_memory(int* x) { return (*x << 24) >> 24; } The build flags are "-march=rv64g -mabi=lp64d -O2" The current compilation results are as follows, slliw a0,a0,0

Re: [PATCH v1] [RFC] Improve folding for comparisons with zero in tree-ssa-forwprop.

On 3/20/23 08:01, Manolis Tsamis wrote: On Fri, Mar 17, 2023 at 10:31 AM Richard Biener wrote: On Thu, Mar 16, 2023 at 4:27 PM Manolis Tsamis wrote: For this C testcase: void g(); void f(unsigned int *a) { if (++*a == 1) g(); } GCC will currently emit a comparison with 1 by usi

Re: [PATCH] vect: Check that vector factor is a compile-time constant

On 3/17/23 10:57, Palmer Dabbelt wrote: I'm a little bit confused about what the proposal is here: is the idea to have a branch based on gcc-13 where we coordinate work before it lands on trunk, or a branch based on gcc-13 where we backport autovec-related patches once they've landed on t

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

On 3/23/23 10:53, Peter Bergner wrote: On 3/23/23 11:32 AM, Jeff Law via Gcc-patches wrote: On 3/23/23 10:29, Peter Bergner wrote: I'm sorry that I don't know how REE works. Why can't it optimize this? I see in the REE dump: (insn 20 18 22 3 (set (reg:DI 4 4) (zero_

[PATCH] Fix native MSYS2 build failure [PR108865, PR109188]

Patch to fix native Windows MSYS2 package build failures. The patch has been confirmed by both original reporters in the PRs, and myself. cc'd mingw-w64 maintainer for mingw-w64-specific issue. 0001-Fix-native-MSYS2-build-failure-PR108865-PR109188.patch Description: Binary data

[pushed] c++: constexpr PMF conversion [PR105996]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here, we were calling build_reinterpret_cast regardless of whether there was actually a cast, and that now sets REINTERPRET_CAST_P. But that optimization seems dodgy anyway, as it involves NOP_EXPR from one RECORD_TYPE to another and we try

Re: [PATCH 1/2] c++: improve "NTTP argument considered unused" fix [PR53164, PR105848]

On Thu, Mar 23, 2023 at 5:18 PM Patrick Palka wrote: > > r13-995-g733a792a2b2e16 worked around the problem of FUNCTION_DECL > template arguments not always getting marked as odr-used by redundantly > calling mark_used on the substituted ADDR_EXPR callee of a CALL_EXPR. > This is just a narrow work

[PATCH 2/2] c++: duplicate "use of deleted fn" diagnostic [PR106880]

Here we're issuing a duplicate diagnostic for the use of the deleted foo, first from the CALL_EXPR case of tsubst_copy_and_build (which doesn't exit early upon failure), and again from from build_over_call when rebuilding the substituted CALL_EXPR. We can fix this by exiting early upon failure of

[PATCH 1/2] c++: improve "NTTP argument considered unused" fix [PR53164, PR105848]

r13-995-g733a792a2b2e16 worked around the problem of FUNCTION_DECL template arguments not always getting marked as odr-used by redundantly calling mark_used on the substituted ADDR_EXPR callee of a CALL_EXPR. This is just a narrow workaround however, since using a FUNCTION_DECL as a template argume

Re: [PATCH RFC] c-family: -Wsequence-point and COMPONENT_REF [PR107163]

On Thu, Mar 23, 2023 at 04:35:07PM -0400, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu. Jakub, does this make sense to you? Do we have a > way of testing for compile-hog regressions? > > -- 8< -- > > The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF > as sequenced

[COMMITTED] testsuite: Xfail gcc.dg/tree-ssa/ssa-fre-100.c for ! natural_alignment_32

Tested native x86_64-linux and cris-elf. The "recent patch to gcc.dg/tree-ssa/pr100359.c" refers to r13-6838. Committed as obvious after that commit. -- >8 -- The test gcc.dg/tree-ssa/ssa-fre-100.c fails the scan-tree-dump-not fre1 "baz" for at least m68k-linux, pru-elf, and cris-elf according to

[PATCH RFC] c-family: -Wsequence-point and COMPONENT_REF [PR107163]

Tested x86_64-pc-linux-gnu. Jakub, does this make sense to you? Do we have a way of testing for compile-hog regressions? -- 8< -- The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF as sequenced in C++17, and COMPONENT_REF as well. But this is unnecessary for COMPONENT_R

Re: Fwd: [V5][PATCH 2/2] Update documentation to clarify a GCC extension

On Thu, 23 Mar 2023, Qing Zhao via Gcc-patches wrote: > +Wgnu-variable-sized-type-not-at-end > +C C++ Var(warn_variable_sized_type_not_at_end) Warning > +Warn about structures or unions with C99 flexible array members are not > +at the end of a structure. I think there's at least one word missing

[OG12][committed] Fortran/OpenMP: Fix 'alloc' and 'from' mapping for allocatable components

This is about OpenMP's "deep mapping" of allocatable components of derived types. The basic feature is on OG12 (and OG11) but yet in GCC mainline. The old submissions are at https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593704.html My plan is to get the whole feature into GCC 14 once tr

Re: [PATCH] PR tree-optimization/109238 - Ranger cache dominator queries should ignore backedges.

On Thu, Mar 23, 2023 at 02:37:01PM -0400, Andrew MacLeod via Gcc-patches wrote: > PS I have not managed to produce a reduced testcase yet.. If I do I will > supply it. Here is one: /* PR tree-optimization/10923 */ /* { dg-do compile } */ /* { dg-options "-O2 -Wall" } */ void foo (void *) __attrib

Re: Fwd: [V5][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

On Thu, 23 Mar 2023, Qing Zhao via Gcc-patches wrote: > gcc/c/ChangeLog: > > PR tree-optimization/101832 > * c-decl.cc (finish_struct): Set TYPE_INCLUDE_FLEXARRAY for > struct/union type. The C front-end changes are OK (supposing the original patch has correct whitespace, sinc

[PATCH] PR tree-optimization/109238 - Ranger cache dominator queries should ignore backedges.

Detailed info in the PR. As we walk the DOM tree to calculate ranges, any block with multiple predecessors is processed by evaluating and unioning incoming values. This catches more complex cases where the dominator node itself may not carry range adjustments that we care about. What was mis

Re: [wwwdocs] Document support for znver4 in gcc-13/changes.html

Hello, On Wed, Mar 22 2023, Richard Biener wrote: > On Tue, Mar 21, 2023 at 8:25 PM Martin Jambor wrote: >> >> Hello, >> >> is the following item documenting that gcc13 can generate code for Zen 4 >> OK for the changes.html file on the web? > > OK. thanks. > Note the gcc-12 changes for the upco

[PATCH] c: [PR84900] cast of compound literal does not cause the code to become a non-lvalue

The problem here is after r0-92187-g2ec5deb5c3146c, maybe_lvalue_p would return false for compound literals which causes non_lvalue_loc not to wrap the expression with a NON_LVALUE_EXPR unlike before when it return true as it returns true for all language specific tree codes. This fixes that overs

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

On 3/23/23 11:32 AM, Jeff Law via Gcc-patches wrote: > On 3/23/23 10:29, Peter Bergner wrote: >> I'm sorry that I don't know how REE works. Why can't it optimize this? >> I see in the REE dump: >> >> (insn 20 18 22 3 (set (reg:DI 4 4) >>(zero_extend:DI (reg:QI 4 4 [orig:120

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

On 3/23/23 10:29, Peter Bergner wrote: https://gcc.gnu.org/PR41742 These are not addressed in the trunk patch, because int c is not initialized with registers and for this reason we cannot eliminate them. If we initialize int c then zero extension goes away. I'm sorry that I don't kn

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

On 3/23/23 8:47 AM, Jeff Law wrote: > On 3/23/23 04:38, Ajit Agarwal wrote: >> * ree.cc: Modification for AND opcode support to eliminate >> unnecessary signed extension. >> * testsuite/g++.target/powerpc/sext-elim.C: New tests. > Just a note. I'll look at this once the trunk is open

[PATCH] tree-optimization/107569 - avoid wrecking earlier folding in FRE/PRE

The following avoids picking up dead code left over from folding during FRE/PRE, effectively undoing propagations. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/107569 * tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_stmt): Do not pu

[PATCH] lto/109263 - lto-wrapper and -g0 -ggdb

The following makes lto-wrapper deal with non-combined debug disabling / enabling option combinations properly. Interestingly -gno-dwarf also enables debug. Bootstrap / regtest running on x86_64-unknown-linux-gnu. OK? Or do we want to try harder to zap earlier -g0 when later -g* appear?

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

On 23/03/23 7:17 pm, Jeff Law wrote: > > > On 3/23/23 04:38, Ajit Agarwal wrote: >> >> Hello All: >> >> This patch removed unnecessary signed extension elimination in ree pass. >> Bootstrapped and regtested on powerpc64-linux-gnu. >> >> >> Thanks & Regards >> Ajit >> >> rtl-optimization: p

[PATCH] tree-optimization/109262 - ICE with non-call EH and forwprop

The recent combining of complex part loads to a complex load missed to account for non-call EH. Bootstrapped and tested on x86_64-unknwon-linux-gnu, pushed. PR tree-optimization/109262 * tree-ssa-forwprop.cc (pass_forwprop::execute): When combining a piecewise complex load

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

Hello Peter: On 23/03/23 6:08 pm, Peter Bergner wrote: > On 3/23/23 5:38 AM, Ajit Agarwal wrote: >> This patch removed unnecessary signed extension elimination in ree pass. >> Bootstrapped and regtested on powerpc64-linux-gnu. >> >> >> Thanks & Regards >> Ajit >> >> rtl-optimization: ppc back

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

Hello Peter: On 23/03/23 6:08 pm, Peter Bergner wrote: > On 3/23/23 5:38 AM, Ajit Agarwal wrote: >> This patch removed unnecessary signed extension elimination in ree pass. >> Bootstrapped and regtested on powerpc64-linux-gnu. >> >> >> Thanks & Regards >> Ajit >> >> rtl-optimization: ppc back

[PATCH] c++: outer 'this' leaking into local class [PR106969]

Here when resolving the implicit object for '&wrapped' within the local class Foo, we expect to obtain a dummy object of type Foo& since there's no 'this' available in this context. And yet at this point current_class_ref still corresponds to the outer class Context (and is const), which confuses

Re: [PATCH] ranger: Ranger meets aspell

On 3/23/23 15:20, Jakub Jelinek wrote: On Thu, Mar 23, 2023 at 03:05:45PM +0100, Aldy Hernandez wrote: On 3/23/23 14:32, Jakub Jelinek wrote: Hi! I've noticed a comment typo in tree-vrp.cc and decided to quickly skim aspell -c on the ranger sources (with quick I on everything that looked

Re: [PATCH] ranger: Ranger meets aspell

On Thu, Mar 23, 2023 at 03:05:45PM +0100, Aldy Hernandez wrote: > > > On 3/23/23 14:32, Jakub Jelinek wrote: > > Hi! > > > > I've noticed a comment typo in tree-vrp.cc and decided to quickly > > skim aspell -c on the ranger sources (with quick I on everything that > > looked ok or roughly ok). >

(testsuite] Skip gnat.dg/div_zero.adb on Aarch64

For the same reason as on PowerPC. Tested on Aarch64/Linux, applied on the mainline and 12 branch. 2023-03-23 Eric Botcazou * gnat.dg/div_zero.adb: Skip for aarch64*-*-* targets. -- Eric Botcazoudiff --git a/gcc/testsuite/gnat.dg/div_zero.adb b/gcc/testsuite/gnat.dg/div_zero.adb in

Re: [PATCH] ranger: Ranger meets aspell

On 3/23/23 14:32, Jakub Jelinek wrote: Hi! I've noticed a comment typo in tree-vrp.cc and decided to quickly skim aspell -c on the ranger sources (with quick I on everything that looked ok or roughly ok). But not being a native English speaker, I could get stuff wrong. The most questionable s

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

On 3/23/23 04:38, Ajit Agarwal wrote: Hello All: This patch removed unnecessary signed extension elimination in ree pass. Bootstrapped and regtested on powerpc64-linux-gnu. Thanks & Regards Ajit rtl-optimization: ppc backend generates unnecessary signed extension. Elimina

[OG12][committed] Fortran: Add attr.class_ok check for generate_callback_wrapper

On OG12, the OpenMP deep-mapping support added a callback procedure to the vtable. That one did not handle error recovery well (ICE when a CLASS component as not (class_)ok. The attached patch has been committed as https://gcc.gnu.org/g:9c18db65914a751e4a1d9330ccc1659fe5ef270d and applies only

[PATCH] ranger: Ranger meets aspell

Hi! I've noticed a comment typo in tree-vrp.cc and decided to quickly skim aspell -c on the ranger sources (with quick I on everything that looked ok or roughly ok). But not being a native English speaker, I could get stuff wrong. The most questionable seems 3 occurrences of involutary/involutory,

Fwd: [V5][PATCH 2/2] Update documentation to clarify a GCC extension

Ping… Please let me know if you have any further comments on the patch. thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [V5][PATCH 2/2] Update documentation to clarify a GCC extension Date: March 16, 2023 at 5:47:15 PM EDT To: jos...@codesourcery.co

Fwd: [V5][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

Ping… Please let me know if you have any further comments on the patch. thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [V5][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832] Date: March 16, 2023

Fwd: [V5][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

Ping… Please let me know if you have any further comments on the patch. thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [V5][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size Date: March 16, 2023 at 5:

Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

On 3/23/23 5:38 AM, Ajit Agarwal wrote: > This patch removed unnecessary signed extension elimination in ree pass. > Bootstrapped and regtested on powerpc64-linux-gnu. > > > Thanks & Regards > Ajit > > rtl-optimization: ppc backend generates unnecessary signed extension. > > Elimina

Re: Blockchain Consulting

Hello, I am writing to follow up on my email. /*Can we get on a call on *//*Monday (27th March)*//*or Tuesday (28th March) so we can discuss Blockchain Solution requirements you may have? */ Please suggest a day and time to connect and also share the best number to reach you. Thank you Jes

[committed] amdgcn: Fix register size bug

This patch fixes a bug in which the function prologue would save more registers to the stack than there was space allocated. This would cause data corruption when the epilogue restored the registers if a child function had overwritten that memory. The problem was caused by insn constraints tha

[committed] amdgcn: vec_extract no-op insns

This patch adds new pseudo-insns for no-op vector extractions. These were previously modelled as simple move instructions, but the register allocator has unhelpful special handling for these that triggered spills to memory. Modelling them as a vec_select does the right thing in the register al

[PATCH] libstdc++: use __bool_constant instead of integral_constant

In the type_traits header, both integral_constant and __bool_constant are used. This patch unifies those usages into __bool_constant. libstdc++-v3/ChangeLog: * include/std/type_traits: Use __bool_constant instead of integral_constant. Signed-off-by: Ken Matsui --- libstdc++-v3/

Re: [PATCH] libstdc++: use __bool_constant instead of integral_constant

On Thu, Mar 23, 2023 at 3:56 AM Ville Voutilainen wrote: > > On Thu, 23 Mar 2023 at 12:53, Ken Matsui wrote: > > > > DCO sign-off is indeed more light-weight, and sure, it's becoming more > > > common > > > since it's relatively new as an option. > > > > Thank you! > > > > To add a DCO sign-off,

Re: [PATCH] libstdc++: use __bool_constant instead of integral_constant

On Thu, 23 Mar 2023 at 12:53, Ken Matsui wrote: > > DCO sign-off is indeed more light-weight, and sure, it's becoming more > > common > > since it's relatively new as an option. > > Thank you! > > To add a DCO sign-off, do I need to bump up the subject line to [PATCH v2]? No. The format of the

Re: [PATCH] libstdc++: use __bool_constant instead of integral_constant

On Thu, Mar 23, 2023 at 3:46 AM Ville Voutilainen wrote: > > On Thu, 23 Mar 2023 at 12:18, Ken Matsui via Libstdc++ > wrote: > > > > Thank you so much for your review! > > > > This is my first time contributing to GCC, so I do not have a GCC > > copyright assignment. I googled those two ways, but

Re: [PATCH] libstdc++: use __bool_constant instead of integral_constant

On Thu, 23 Mar 2023 at 12:18, Ken Matsui via Libstdc++ wrote: > > Thank you so much for your review! > > This is my first time contributing to GCC, so I do not have a GCC > copyright assignment. I googled those two ways, but I am still > confused... Is it correct that the DCO sign-off has been get

[PATCH] rtl-optimization: ppc backend generates unnecessary signed extension.

Hello All: This patch removed unnecessary signed extension elimination in ree pass. Bootstrapped and regtested on powerpc64-linux-gnu. Thanks & Regards Ajit rtl-optimization: ppc backend generates unnecessary signed extension. Eliminate unnecessary redundant signed extension.

Re: [PATCH] libstdc++: use __bool_constant instead of integral_constant

Thank you so much for your review! This is my first time contributing to GCC, so I do not have a GCC copyright assignment. I googled those two ways, but I am still confused... Is it correct that the DCO sign-off has been getting more common recently? If so, I will put the sign-off into all my patc

[PING] Re: [PATCH 2/2] ivopts: Revert register pressure cost when there are enough registers.

Ping for patch from December 2022: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608896.html

[PATCH] ipa: Avoid another ICE when dealing with type-incompatibilities (PR 108959)

Hi, PR 108959 shows one more example where undefined code with type incompatible accesses to stuff passed in parameters can cause an ICE because we try to create a VIEW_CONVERT_EXPR of mismatching sizes: 1. IPA-CP tries to push one type from above, 2. IPA-SRA (correctly) decides the parameter is

[PING] Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity.

Ping for patch from December 2022: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608895.html

RE: [PATCH] RISC-V: Bugfix for rvv bool mode size adjustment

Great! Thank you ;) -Original Message- From: Kito Cheng Sent: Thursday, March 23, 2023 4:41 PM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode size adjustment committed, thanks for the reminder

[Patch,v4] Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings

[GCC 13 vs GCC 14] I am unsure whether this should still go to GCC 13 or not. It is somewhat larger albeit well contained (Fortran, only OpenMP, ...) and fixes real-world bugs, but it is not a regression - and we are meanwhile slowly approaching the release. An alternative would be to go to GCC

Re: [PATCH] libstdc++: use __bool_constant instead of integral_constant

On Thu, 23 Mar 2023 at 02:06, Ken Matsui via Libstdc++ < libstd...@gcc.gnu.org> wrote: > In the type_traits header, both integral_constant and __bool_constant > are used. Yes, this is just because we didn't have __bool_constant originally, and nobody has needed to touch the traits that still use

Re: [PATCH] tree-vect-generic: Fix up expand_vector_condition [PR109176]

On Thu, 23 Mar 2023, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs on aarch64-linux, because > expand_vector_condition attempts to piecewise lower SVE > d_3 = a_1(D) < b_2(D); > _5 = VEC_COND_EXPR ; > which isn't possible - nunits_for_known_piecewise_op ICEs but > the rest of the

Re: [PATCH] RISC-V: costs: miscomputed shiftadd_cost triggering synth_mult [PR/108987]

Committed 2 weeks ago but apparently I didn't send mail to say that, thanks Vineet. On Thu, Mar 2, 2023 at 3:56 AM Philipp Tomsich wrote: > > On Wed, 1 Mar 2023 at 20:53, Vineet Gupta wrote: > > > > This showed up as dynamic icount regression in SPEC 531.deepsjeng with > > upstream > > gcc (vs.

Re: [PATCH] RISC-V: Bugfix for rvv bool mode size adjustment

committed, thanks for the reminder :) On Mon, Mar 13, 2023 at 9:40 AM Li, Pan2 via Gcc-patches wrote: > > Kindly reminder for this PR. Thank you all in advance. > > Pan > > -Original Message- > From: Li, Pan2 > Sent: Wednesday, March 8, 2023 7:31 PM > To: gcc-patches@gcc.gnu.org > Cc: juz

Re: [PATCH] RISC-V: Fix loss of function to script 'multilib-generator'

Nice catch, committed to the trunk! On Tue, Mar 21, 2023 at 3:39 PM Songhe Zhu wrote: > > The arch 'rv32imac' will not be created when excuting > './multilib-generator rv32imc-ilp32--a' > > The output is: > MULTILIB_OPTIONS = march=rv32imc mabi=ilp32 > MULTILIB_DIRNAMES = rv32imc ilp32 > MULTILIB

[PATCH] tree-vect-generic: Fix up expand_vector_condition [PR109176]

Hi! The following testcase ICEs on aarch64-linux, because expand_vector_condition attempts to piecewise lower SVE d_3 = a_1(D) < b_2(D); _5 = VEC_COND_EXPR ; which isn't possible - nunits_for_known_piecewise_op ICEs but the rest of the code assumes constant number of elements too. expand_vect

Re: [PATCH] PR target/105325, Make load/cmp fusion know about prefixed loads

Hi Mike, Thanks for fixing this, some minor comments are inlined below. on 2023/3/22 07:53, Michael Meissner wrote: > The issue with the bug is the power10 load GPR + cmpi -1/0/1 fusion > optimization generates illegal assembler code. > > Ultimately the code was dying because the fusion load + c

[PATCH] In the ready lists of pipeline, put unrecog insns (such as CLOBBER, USE) at the latest to issue.

Unrecog insns (such as CLOBBER, USE) does not represent real instructions, but in the process of pipeline optimization, they will wait for transmission in ready list like other insns, without considering resource conflicts and cycles. This results in a multi-issue CPU architecture that can be