RE: [PATCH v3 2/5] Match: Add interface match_cond_with_binary_phi for true/false arg

Thanks Richard for comments. > Yes, inline both CFG matches and unify them - there should be exactly > three cases at > the moment. And "duplicate" computing the true/false arg into the > respective cases > since it's trivial which edge(s) to look at. Got it, will resend the v4 series for this c

Re: [PATCH v3 2/5] Match: Add interface match_cond_with_binary_phi for true/false arg

On Thu, Sep 12, 2024 at 3:41 AM Li, Pan2 wrote: > > Thanks Richard for comments. > > > why would arg_edge depend on whether t0 is INTEGER_CST or not? > Because the edge->src of INTEGER_CST points to the cond block which cannot > match the > edge->dest of the cond_block. For example as below, the

Re: [PATCH 1/2] aarch64: Improve vector constant generation using SVE INDEX instruction [PR113328]

On Thu, Sep 12, 2024 at 2:53 AM Pengxuan Zheng wrote: > > SVE's INDEX instruction can be used to populate vectors by values starting > from > "base" and incremented by "step" for each subsequent value. We can take > advantage of it to generate vector constants if TARGET_SVE is available and > th

Re: [PATCH] s390: Fix strict_low_part generation

On 8/16/24 09:14, Stefan Schulze Frielinghaus wrote: In s390_expand_insv(), if generating code for ICM et al. src is a MEM and gen_lowpart might force src into a register such that we end up with patterns which do not match anymore. Use adjust_address() instead in order to preserve a MEM. Furth

Re: [PATCH] cselib: Discard useless locs of preserved VALUEs [PR116627]

On Wed, Sep 11, 2024 at 11:26:27PM +0200, Jakub Jelinek wrote: > I think we need to discuard useless locs even from the preserved VALUEs. > That IMHO shouldn't create any further useless VALUEs, the preserved > VALUEs are never useless, so we don't need to iterate with it, can do it > just once, bu

Re: [PATCH] s390: Fix TF to FPRX2 conversion [PR115860]

On 9/12/24 08:14, Stefan Schulze Frielinghaus wrote: .. Right, so offsettable_memref_p only ensures that any resulting address is a valid general address.  So we have to manually check for short displacement. Maybe something along the lines: diff --git a/gcc/config/s390/s390.cc b/gcc/config/s

Re: [PATCH] s390: Fix TF to FPRX2 conversion [PR115860]

Ok, Thanks! Andreas On 8/16/24 09:41, Stefan Schulze Frielinghaus wrote: Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1 survive register allocation. This in turn leads to wrong register renaming. Keeping the current approach would mean we need two insns for *tf_to_fprx2_

RE: [PATCH v2] RISC-V: Eliminate latter vsetvl when fused

Committed. Pan From: 钟居哲 Sent: Thursday, September 12, 2024 12:40 PM To: Bohan Lei ; gcc-patches Cc: Li, Pan2 Subject: Re: [PATCH v2] RISC-V: Eliminate latter vsetvl when fused LGTM juzhe.zh...@rivai.ai From: Bohan Lei

Re: [PATCH] s390: Fix TF to FPRX2 conversion [PR115860]

On Wed, Sep 11, 2024 at 08:57:23PM +0200, Ilya Leoshkevich wrote: > On Wed, 2024-09-11 at 16:44 +0200, Stefan Schulze Frielinghaus wrote: > > On Wed, Sep 11, 2024 at 01:59:48PM +0200, Ilya Leoshkevich wrote: > > > On Wed, 2024-09-11 at 13:34 +0200, Stefan Schulze Frielinghaus > > > wrote: > > > > O

Re: [PATCH v2] Enable V2BF/V4BF vec_cmp with AVX10.2 vcmppbf16

On Thu, Sep 12, 2024 at 9:55 AM Levy Hsu wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > Ok for trunk? Ok. > > gcc/ChangeLog: > > * config/i386/i386.cc (ix86_get_mask_mode): > Enable BFmode for targetm.vectorize.get_mask_mode with AVX10.2. > * config/

[PATCH] i386: Implement Thread Local Storage on Windows

Hello everyone, This patch is an initial implementation of native Thread Local Storage on Windows, which currently emulates TLS via emutls. This was heavily referenced from Daniel Green's original work with Windows TLS from a decade ago, so credit should be attributed to him as well (https://gi

Re: [PATCH v2] RISC-V: Eliminate latter vsetvl when fused

LGTM juzhe.zh...@rivai.ai From: Bohan Lei Date: 2024-09-12 12:38 To: gcc-patches CC: juzhe.zhong Subject: [PATCH v2] RISC-V: Eliminate latter vsetvl when fused Resent to cc Juzhe. -- Hi all, A simple assembly check has been added in this version. Previous version: https://gcc.gnu.org

[PATCH v2] RISC-V: Eliminate latter vsetvl when fused

Resent to cc Juzhe. -- Hi all, A simple assembly check has been added in this version. Previous version: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662783.html Thanks, Bohan -- The current vsetvl pass eliminates a vsetvl instruction when the previous info is "available,"

[PATCH v1] RISC-V: Implement SAT_ADD for signed integer vector

From: Pan Li This patch would like to implement the ssadd for vector integer. Aka form 1 of ssadd vector. Form 1: #define DEF_VEC_SAT_S_ADD_FMT_1(T, UT, MIN, MAX) \ void __attribute__((noinline)) \ vec_sat_s_add_##T##_fmt_1 (T *out

Re: RE: [PATCH 2/2] RISC-V: Eliminate latter vsetvl when fused

Could you CC to me ? I can't reply that patch directly. juzhe.zh...@rivai.ai From: Bohan Lei Date: 2024-09-12 10:38 To: Bohan Lei CC: gcc-patches; juzhe.zhong Subject: RE: [PATCH 2/2] RISC-V: Eliminate latter vsetvl when fused An updated version has been submitted: https://gcc.gnu.org/pipermai

RE: [PATCH 2/2] RISC-V: Eliminate latter vsetvl when fused

An updated version has been submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662854.html -- From:Bohan Lei Send Time:2024 Sep. 11 (Wed.) 17:12 To:"gcc-patches" Subject:[PATCH 2/2] RISC-V: Eliminate latter vsetvl wh

[PATCH v2] RISC-V: Eliminate latter vsetvl when fused

Hi all, A simple assembly check has been added in this version. Previous version: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662783.html Thanks, Bohan -- The current vsetvl pass eliminates a vsetvl instruction when the previous info is "available," but does not when "compatibl

Re: [PATCH v2] c++: deleting explicitly-defaulted functions [PR116162]

On 9/11/24 4:08 PM, Marek Polacek wrote: On Wed, Sep 11, 2024 at 01:19:53PM -0400, Jason Merrill wrote: On 9/11/24 12:54 PM, Marek Polacek wrote: + auto_diagnostic_group d; + /* We used to emit a hard error, so this uses 0 rather than +OPT_Wpedantic. */ + if

Re: [PATCH v2] c++: ICE with TTP [PR96097]

On 9/11/24 4:36 PM, Marek Polacek wrote: On Wed, Sep 11, 2024 at 11:26:56AM -0400, Jason Merrill wrote: On 9/11/24 10:53 AM, Patrick Palka wrote: On Wed, 11 Sep 2024, Patrick Palka wrote: On Wed, 11 Sep 2024, Patrick Palka wrote: On Wed, 4 Sep 2024, Marek Polacek wrote: On Wed, Sep 04, 20

Re: [PATCH] JSON dumping for GENERIC trees

On Wed, Sep 11, 2024 at 6:51 PM wrote: > > From: Thor C Preimesberger > > This patch allows the compiler to dump GENERIC trees as JSON objects. > > The dump flag -fdump-tree-original-json dumps each fndecl node in the > C frontend's gimplifier as a JSON object and traverses related nodes > in an

[PATCH v2] Enable V2BF/V4BF vec_cmp with AVX10.2 vcmppbf16

Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk? gcc/ChangeLog: * config/i386/i386.cc (ix86_get_mask_mode): Enable BFmode for targetm.vectorize.get_mask_mode with AVX10.2. * config/i386/mmx.md (vec_cmpqi): Implement vec_cmpv2bfqi and vec_cmpv

[PATCH] JSON dumping for GENERIC trees

From: Thor C Preimesberger This patch allows the compiler to dump GENERIC trees as JSON objects. The dump flag -fdump-tree-original-json dumps each fndecl node in the C frontend's gimplifier as a JSON object and traverses related nodes in an analagous manner as to raw-dumping. Some JSON parse

Ping: [PATCH v3 1/2] c++: improve location of parsed RETURN_EXPRs

Jason Merrill writes: >> This is the new output - the diagnostics no longer expand that macro, >> since the location is not wholly contained within it. The relevant part >> of the diagnostics after the change is: >> --8<---cut here---start->8--- >>

RE: [PATCH v3 2/5] Match: Add interface match_cond_with_binary_phi for true/false arg

Thanks Richard for comments. > why would arg_edge depend on whether t0 is INTEGER_CST or not? Because the edge->src of INTEGER_CST points to the cond block which cannot match the edge->dest of the cond_block. For example as below, the first arg of PHI is 255(2), which cannot match neither goto

RE: [PATCH 1/2] RISC-V: Fix vl_used_by_non_rvv_insn logic of vsetvl pass

Committed, thanks Juzhe and garthlei. Pan From: 钟居哲 Sent: Wednesday, September 11, 2024 7:36 PM To: gcc-patches Cc: Li, Pan2 ; Robin Dapp ; jeffreyalaw ; kito.cheng Subject: [PATCH 1/2] RISC-V: Fix vl_used_by_non_rvv_insn logic of vsetvl pass Hi, garthlei. Thanks for fixing it. I see, you a

Re: [PATCH v5] Provide new GCC builtin __builtin_counted_by_ref [PR116016]

> On Sep 11, 2024, at 18:16, Bill Wendling wrote: > > On Wed, Sep 11, 2024 at 2:13 PM Qing Zhao wrote: >> >> compared to the 4th version, the changes are (address Jacub's concerns): >> >> 1. change the global "in_builtin_counted_by_ref" from a boolean to an int; >> 2. delete the label for th

RE: [PATCH] aarch64: Improve vector constant generation using SVE INDEX instruction [PR113328]

> Pengxuan Zheng writes: > > SVE's INDEX instruction can be used to populate vectors by values > > starting from "base" and incremented by "step" for each subsequent > > value. We can take advantage of it to generate vector constants if > > TARGET_SVE is available and the base and step values are

[PATCH 2/2] aarch64: Improve part-variable vector initialization with SVE INDEX instruction [PR113328]

We can still use SVE's INDEX instruction to construct vectors even if not all elements are constants. For example, { 0, x, 2, 3 } can be constructed by first using "INDEX #0, #1" to generate { 0, 1, 2, 3 }, and then set the elements which are non-constants separately. PR target/113328 gcc

[PATCH 1/2] aarch64: Improve vector constant generation using SVE INDEX instruction [PR113328]

SVE's INDEX instruction can be used to populate vectors by values starting from "base" and incremented by "step" for each subsequent value. We can take advantage of it to generate vector constants if TARGET_SVE is available and the base and step values are within [-16, 15]. For example, with the f

Re: [PATCH] libcpp, v4: Add support for gnu::base64 #embed parameter

On Fri, 30 Aug 2024, Jakub Jelinek wrote: > +should be no newlines in the string literal and because this parameter > +is meant namely for use by the preprocessor itself, there is no support > +for any escape sequences in the string literal argument. If > @code{gnu::base64} Given the "no escape

Re: [PATCH] libcpp, v3: Add support for gnu::offset #embed/__has_embed parameter

On Fri, 30 Aug 2024, Jakub Jelinek wrote: > On Fri, Aug 16, 2024 at 04:58:58PM +, Joseph Myers wrote: > > On Thu, 15 Aug 2024, Jakub Jelinek wrote: > > > > > + else > > > + { > > > + if (res > INTTYPE_MAXIMUM (off_t)) > > > + cpp_error_with_line (pfile, CPP_DL_ERROR, loc,

Re: [PATCH] libcpp, c-family, v4: Add (dumb) C23 N3017 #embed support [PR105863]

On Fri, 30 Aug 2024, Jakub Jelinek wrote: > Here is an updated version of the patch which uses a new flag in lang_flags > to control this. > I haven't touched the macro expansion or lack thereof from the earlier > version though. This patch is OK. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH v5] Provide new GCC builtin __builtin_counted_by_ref [PR116016]

On Wed, Sep 11, 2024 at 2:13 PM Qing Zhao wrote: > > compared to the 4th version, the changes are (address Jacub's concerns): > > 1. change the global "in_builtin_counted_by_ref" from a boolean to an int; > 2. delete the label for the error handling code, and decress the global >"in_builtin_co

Merch/Apparel hats supply

Hi   Have a nice day!   This is Dorothy from WellSucceed Embroidery Limited in China.    May I ask if we have the great honor to be your supplier and your responsible helper?   Could you please put us in contact with your purchasing team in case the mail goes into the spam folder?   We are speciali

[PATCH] libcpp: Implement clang -Wheader-guard warning [PR96842]

Hi! The following patch implements the clang -Wheader-guard warning, which warns if a valid multiple inclusion header guard's #ifndef/#if !defined directive is immediately (no other non-line directives nor other (non-comment) tokens in between) followed by #define directive for some different macr

[PATCH] c++: Disable deprecated/unavailable diagnostics when creating thunks for methods with such attributes [PR116636]

Hi! On the following testcase, we emit false positive warnings/errors about using the deprecated or unavailable methods when creating thunks for them, even when nothing (in the testcase so far) actually used those. The following patch temporarily disables that diagnostics when creating the thunks

[PATCH] cselib: Discard useless locs of preserved VALUEs [PR116627]

Hi! remove_useless_values iteratively discards useless locs (locs of cselib_val which refer to non-preserved VALUEs with no locations), which in turn can make further values useless until no further VALUEs are made useless and then discards the useless VALUEs. Preserved VALUEs (something done dur

[PATCH v5] Provide new GCC builtin __builtin_counted_by_ref [PR116016]

compared to the 4th version, the changes are (address Jacub's concerns): 1. change the global "in_builtin_counted_by_ref" from a boolean to an int; 2. delete the label for the error handling code, and decress the global "in_builtin_counted_by_ref" before each break; the 4th version compared t

[PATCH v2] c++: ICE with TTP [PR96097]

On Wed, Sep 11, 2024 at 11:26:56AM -0400, Jason Merrill wrote: > On 9/11/24 10:53 AM, Patrick Palka wrote: > > On Wed, 11 Sep 2024, Patrick Palka wrote: > > > > > On Wed, 11 Sep 2024, Patrick Palka wrote: > > > > > > > On Wed, 4 Sep 2024, Marek Polacek wrote: > > > > > > > > > On Wed, Sep 04, 20

[PATCH v2] c++: deleting explicitly-defaulted functions [PR116162]

On Wed, Sep 11, 2024 at 01:19:53PM -0400, Jason Merrill wrote: > On 9/11/24 12:54 PM, Marek Polacek wrote: > > + auto_diagnostic_group d; > > + /* We used to emit a hard error, so this uses 0 rather than > > +OPT_Wpedantic. */ > > + if (pedwarn (DECL_SOURCE_LOCATION (fn), 0, >

Re: [PATCH] s390: Fix TF to FPRX2 conversion [PR115860]

On Wed, 2024-09-11 at 16:44 +0200, Stefan Schulze Frielinghaus wrote: > On Wed, Sep 11, 2024 at 01:59:48PM +0200, Ilya Leoshkevich wrote: > > On Wed, 2024-09-11 at 13:34 +0200, Stefan Schulze Frielinghaus > > wrote: > > > On Wed, Sep 11, 2024 at 01:22:30PM +0200, Ilya Leoshkevich wrote: > > > > On

Re: [PATCH] c++: Don't ICE to build private access error message [PR116323]

On 9/11/24 7:26 AM, Simon Martin wrote: We currently ICE upon the following code while building the "[...] is private within this context" error message === cut here === class A { enum Enum{}; }; template class Alloc> class B : private Alloc, private A {}; template class Alloc> int B::foo (Enum

Re: [PATCH] c++/modules: Really always track partial specialisations [PR116496]

On 9/11/24 8:51 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK. -- >8 -- My last fix for this issue (PR c++/114947, r15-810) didn't go far enough; I had assumed that the issue where we lost track of partial specialisations we would need to walk

Re: [PATCH] c++: deleting explicitly-defaulted functions [PR116162]

On 9/11/24 12:54 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This PR points out the we're not implementing [dcl.fct.def.default] properly. Consider e.g. struct C { C(const C&&) = default; }; where we wrongly emit an error, but the

[PATCH] c++: deleting explicitly-defaulted functions [PR116162]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This PR points out the we're not implementing [dcl.fct.def.default] properly. Consider e.g. struct C { C(const C&&) = default; }; where we wrongly emit an error, but the move ctor should be just =deleted. According t

[PATCH v1][GCC] aarch64: Add GCS build attributes support.

This patch adds support for aarch64 gcs build attributes. This support includes generating two new assembler directives .aeabi_subsection and .aeabi_attribute. These directives are generated as per the syntax mentioned in spec "Build Attributes for the Arm® 64-bit Architecture (AArch64)" available

Re: [PATCH] c++: decltype(auto) deduction of statement-expression [PR116418]

On 9/10/24 8:35 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/backports? OK, though you might combine the new STMT_EXPR case with the existing LAMBDA_EXPR case; the principle is the same for both. -- >8 -- r8-7538 for PR84968 made s

Re: [PATCH] c++: ICE with TTP [PR96097]

On 9/11/24 10:53 AM, Patrick Palka wrote: On Wed, 11 Sep 2024, Patrick Palka wrote: On Wed, 11 Sep 2024, Patrick Palka wrote: On Wed, 4 Sep 2024, Marek Polacek wrote: On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote: On 9/3/24 6:12 PM, Marek Polacek wrote: Bootstrapped/regtes

Re: [PATCH v1] RISC-V: Fix asm check for Vector SAT_* due to middle-end change

On 9/10/24 5:03 PM, pan2...@intel.com wrote: From: Pan Li The middle-end change makes the effect on the layout of the assembly for vector SAT_*. This patch would like to fix it and make it robust. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/binop/vec_sat_u_add-1.c: Adj

Re: [PATCH] Makefile: Fix typos

On Wed, Sep 11, 2024 at 11:06:40AM -0400, Eric Gallager wrote: > On Wed, Sep 11, 2024 at 7:32 AM Andrew Kreimer wrote: > > > > Fix typos in comments. > > > > Signed-off-by: Andrew Kreimer > > --- > > Makefile.def | 2 +- > > Makefile.in | 4 ++-- > > Makefile.tpl | 4 ++-- > > 3 files changed,

FW: [PATCH 2/2] RISC-V: Eliminate latter vsetvl when fused

Hi Juzhe, > Could you show me what the codegen looks like after this patch ?> I would be > expecting the codegen become: > > foo: >         vsetvli a5,a0,e16,m1,ta,ma >         vmv.x.s a4,v8 >         vadd.vx v9,v8,a4 >         vsetvli zero,a5,e16,m1,ta,ma >         vadd.vv v8,v9,v8 >         re

Re: [PATCH] Makefile: Fix typos

On Wed, Sep 11, 2024 at 7:32 AM Andrew Kreimer wrote: > > Fix typos in comments. > > Signed-off-by: Andrew Kreimer > --- > Makefile.def | 2 +- > Makefile.in | 4 ++-- > Makefile.tpl | 4 ++-- > 3 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/Makefile.def b/Makefile.def > inde

Re: [PATCH] c++: ICE with TTP [PR96097]

On Wed, 11 Sep 2024, Patrick Palka wrote: > On Wed, 11 Sep 2024, Patrick Palka wrote: > > > On Wed, 4 Sep 2024, Marek Polacek wrote: > > > > > On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote: > > > > On 9/3/24 6:12 PM, Marek Polacek wrote: > > > > > Bootstrapped/regtested on x86_64

Re: [PATCH] c++: ICE with TTP [PR96097]

On Wed, 11 Sep 2024, Patrick Palka wrote: > On Wed, 4 Sep 2024, Marek Polacek wrote: > > > On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote: > > > On 9/3/24 6:12 PM, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? > > > > > > The change t

Re: [PATCH] s390: Fix TF to FPRX2 conversion [PR115860]

On Wed, Sep 11, 2024 at 01:59:48PM +0200, Ilya Leoshkevich wrote: > On Wed, 2024-09-11 at 13:34 +0200, Stefan Schulze Frielinghaus wrote: > > On Wed, Sep 11, 2024 at 01:22:30PM +0200, Ilya Leoshkevich wrote: > > > On Wed, 2024-09-11 at 12:35 +0200, Stefan Schulze Frielinghaus > > > wrote: > > > > O

Re: [PATCH] c++: ICE with TTP [PR96097]

On Wed, 4 Sep 2024, Marek Polacek wrote: > On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote: > > On 9/3/24 6:12 PM, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? > > > > The change to return bool seems like unrelated cleanup; please push t

Re: Is it possible to get an old posed Patch from gcc-patches archive??

Qing Zhao writes: > Hi, > > I was trying to study an old posted patch (but was not approved and > committed) in the following link: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561096.html > > However, I cannot get the patch from the attachment part as following: > > -

Re: [PATCH v4] Provide new GCC builtin __builtin_counted_by_ref [PR116016]

> On Sep 10, 2024, at 17:47, Jakub Jelinek wrote: > > On Tue, Sep 10, 2024 at 09:28:04PM +, Qing Zhao wrote: >> @@ -11741,6 +11770,54 @@ c_parser_postfix_expression (c_parser *parser) >>set_c_expr_source_range (&expr, loc, close_paren_loc); >>break; >> } >> + case RID_BUILTIN_COUNT

Is it possible to get an old posed Patch from gcc-patches archive??

Hi, I was trying to study an old posted patch (but was not approved and committed) in the following link: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561096.html However, I cannot get the patch from the attachment part as following: -- next part -- A non-tex

Re: [PATCH v3 2/5] Match: Add interface match_cond_with_binary_phi for true/false arg

On Wed, Sep 11, 2024 at 8:31 AM wrote: > > From: Pan Li > > When matching the cond with 2 args phi node, we need to figure out > which arg of phi node comes from the true edge of cond block, as > well as the false edge. This patch would like to add interface > to perform the action and return th

Re: [PATCH] Fix wrong code out of NRV + RSO + inlining

On Wed, Sep 11, 2024 at 12:38 PM Eric Botcazou wrote: > > > Hmm, it looks to me that the IPA analysis marking the variable readonly > > in the first place is wrong - or that NRV may not be applied to such a > > variable later. Is NRV ever applied to say > > > > static const S s = ...; > > > > s =

Re: [PATCH RFA] libstdc++: fix C header include guards

On Tue, 10 Sept 2024 at 11:12, Jonathan Wakely wrote: > > On Tue, 10 Sept 2024 at 05:10, Jason Merrill wrote: > > > > Tested x86_64-pc-linux-gnu, OK for trunk? > > I'm going to have to do some digging ... I _think_ there's some > obscure reason for this. Maybe a weird bootstrap situation. Or maybe

Re: [PATCH 6/8] gcn: Add else operand to masked loads.

On Wed, 11 Sep 2024, Andrew Stubbs wrote: > On 10/09/2024 10:43, Andrew Stubbs wrote: > > On 06/09/2024 09:47, Robin Dapp wrote: > So we only found two instances of this problem and both were related to > _Bools.  In case you have more cases, it would be greatly appreciated > to ver

Re: [PATCH 6/8] gcn: Add else operand to masked loads.

On 10/09/2024 10:43, Andrew Stubbs wrote: On 06/09/2024 09:47, Robin Dapp wrote: So we only found two instances of this problem and both were related to _Bools.  In case you have more cases, it would be greatly appreciated to verify the series with them.  If you don't mind, would it be possible

[PATCH] tree-optimization/116674 - vectorizable_simd_clone_call and re-analysis

When SLP analysis scraps an instance because it fails to analyze we can end up calling vectorizable_* in analysis mode on a node that was analyzed during the analysis of that instance again. vectorizable_simd_clone_call wasn't expecting that and instead guarded analysis/transform code on populated

[PATCH] c++/modules: Really always track partial specialisations [PR116496]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- My last fix for this issue (PR c++/114947, r15-810) didn't go far enough; I had assumed that the issue where we lost track of partial specialisations we would need to walk again later was limited to partitions (where we alw

Re: [PATCH] c++: Implement for namespace statics CWG 2867 - Order of initialization for structured bindings [PR115769]

On Wed, Sep 11, 2024 at 10:16:18PM +1000, Nathaniel Shead wrote: > In the header_module_p case, it is valid to have internal linkage > definitions (e.g. in an anonymous namespace), but in that case the > {static,tls}_aggregates lists should still be in place to be streamed > and everything should w

Re: [PATCH] c++: Implement for namespace statics CWG 2867 - Order of initialization for structured bindings [PR115769]

On Tue, Sep 10, 2024 at 08:29:58PM +0200, Jakub Jelinek wrote: > Hi! > > The following patch on top of the > https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662507.html > patch adds CWG 2867 support for namespace locals. > > Those vars are just pushed into {static,tls}_aggregates chain,

[PATCH] testsuite: Relax line number match in gfortran.dg/pr95690.f90

The actual line number is target dependent, and immaterial for the test. * gfortran.dg/pr95690.f90: Allow matching error message anywhere. --- gcc/testsuite/gfortran.dg/pr95690.f90 | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/gcc/testsuite/gfortran.dg/pr95690.

Re: [PATCH] s390: Fix TF to FPRX2 conversion [PR115860]

On Wed, 2024-09-11 at 13:34 +0200, Stefan Schulze Frielinghaus wrote: > On Wed, Sep 11, 2024 at 01:22:30PM +0200, Ilya Leoshkevich wrote: > > On Wed, 2024-09-11 at 12:35 +0200, Stefan Schulze Frielinghaus > > wrote: > > > On Wed, Sep 11, 2024 at 11:47:54AM +0200, Ilya Leoshkevich wrote: > > > > On

Re: FW: [PATCH 2/2] RISC-V: Eliminate latter vsetvl when fused

I see the codegen is incorrect before this patch: foo: vsetvli a5,a0,e16,m1,ta,ma vmv.x.s a4,v8 vsetvli a5,a0,e8,mf2,ta,ma ---> wrong VTYPE vadd.vx v9,v8,a4 vsetvli zero,a5,e16,m1,ta,ma vadd.vv v8,v9,v8 ret Could you show me what the codegen

[PATCH 2/2] ipa-cp: One more use of ipa_vr_supported_type_p

Hi, Since we have the predicate, this patch converts one more check for essentially the same thing into its use. It has passed a bootstrap and testsuite on x86_64. I believe it is obvious enough that I can commit it myself and so will do so later today. Thanks, Martin 2024-09-11 Martin Jamb

[PATCH 1/2] ipa: Rename ipa_supports_p to ipa_vr_supported_type_p

Hi, ipa_supports_p is not a name that captures well what the predicate determines. Therefore, this patch renames it to ipa_vr_supported_type_p. This change has been pre-approved by Honza and has passed bootstrap and test-suite on x86_64 and so I will push it to master later today. Thanks, Mart

[PATCH 1/2] RISC-V: Fix vl_used_by_non_rvv_insn logic of vsetvl pass

Hi, garthlei. Thanks for fixing it. I see, you are trying to fix this bug: lui a5,%hi(.LANCHOR0) addia5,a5,%lo(.LANCHOR0) vsetivlizero,2,e8,mf8,ta,ma ---> It should be a4, 2 instead of zero, 2 vle64.v v1,0(a5) --- missing vsetvli a4, a4 here

Re: [PATCH] s390: Fix TF to FPRX2 conversion [PR115860]

On Wed, Sep 11, 2024 at 01:22:30PM +0200, Ilya Leoshkevich wrote: > On Wed, 2024-09-11 at 12:35 +0200, Stefan Schulze Frielinghaus wrote: > > On Wed, Sep 11, 2024 at 11:47:54AM +0200, Ilya Leoshkevich wrote: > > > On Fri, 2024-08-16 at 09:41 +0200, Stefan Schulze Frielinghaus > > > wrote: > > > > C

[PATCH] Makefile: Fix typos

Fix typos in comments. Signed-off-by: Andrew Kreimer --- Makefile.def | 2 +- Makefile.in | 4 ++-- Makefile.tpl | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/Makefile.def b/Makefile.def index 19954e7d731..b502eb63d36 100644 --- a/Makefile.def +++ b/Makefile.def @@ -7

[PATCH] c++: Don't ICE to build private access error message [PR116323]

We currently ICE upon the following code while building the "[...] is private within this context" error message === cut here === class A { enum Enum{}; }; template class Alloc> class B : private Alloc, private A {}; template class Alloc> int B::foo (Enum m) { return 42; } === cut here === The pr

Re: [PATCH] s390: Fix TF to FPRX2 conversion [PR115860]

On Wed, 2024-09-11 at 12:35 +0200, Stefan Schulze Frielinghaus wrote: > On Wed, Sep 11, 2024 at 11:47:54AM +0200, Ilya Leoshkevich wrote: > > On Fri, 2024-08-16 at 09:41 +0200, Stefan Schulze Frielinghaus > > wrote: > > > Currently subregs originating from *tf_to_fprx2_0 and > > > *tf_to_fprx2_1 >

Re: [PATCH] MIPS: Add some floating point instructions support for MIPSr6

On Wed, 2024-09-11 at 16:17 +0800, 梅杰 wrote: > 在 2024/9/10 17:30, Xi Ruoyao 写道: > > On Tue, 2024-09-10 at 16:50 +0800, 梅杰 wrote: > > > As for the function `__builtin_rint`, although it exists, however, after > > > defining the instruction in `mips.md`, GCC still won't generate > > > `RINT.fmt` >

Re: [PATCH v3] c++: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On 10/09/2024 10:29, Jason Merrill wrote: > On 9/10/24 6:10 AM, Alex Coplan wrote: > > On 27/08/2024 10:55, Alex Coplan wrote: > > > Hi, > > > > > > This is a v3 that hopefully addresses the feedback from both Jason and > > > Jakub. v2 was posted here: > > > https://gcc.gnu.org/pipermail/gcc-patc

[r15-3581 Regression] FAIL: gfortran.dg/gomp/interop-1.f90 -O (test for excess errors) on Linux/x86_64

On Linux/x86_64, 4e9265a474def98cb6cdb59c15fbcb7630ba330e is the first bad commit commit 4e9265a474def98cb6cdb59c15fbcb7630ba330e Author: Tobias Burnus Date: Wed Sep 11 09:25:47 2024 +0200 fortran/openmp.cc: Fix var init and locus use to avoid uninit values [PR fortran/116661] caused FA

Re: [PATCH] Fix wrong code out of NRV + RSO + inlining

> Hmm, it looks to me that the IPA analysis marking the variable readonly > in the first place is wrong - or that NRV may not be applied to such a > variable later. Is NRV ever applied to say > > static const S s = ...; > > s = foo (); > > thus a readonly declared LHS? But NRV is only an examp

Re: [PATCH] s390: Fix TF to FPRX2 conversion [PR115860]

On Wed, Sep 11, 2024 at 11:47:54AM +0200, Ilya Leoshkevich wrote: > On Fri, 2024-08-16 at 09:41 +0200, Stefan Schulze Frielinghaus wrote: > > Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1 > > survive register allocation.  This in turn leads to wrong register > > renaming.  Ke

[committed] fortran/openmp.cc: Fix var init and locus use to avoid uninit values [PR fortran/116661]

This patch fixes an issue with unintialized variables causing random ICE. Committed as r15-3581-g4e9265a474def9 * * * However, follow-up work is needed as there are multiple issues: * The check whether something is a identifier (integer parameter) and not just a constant expression did fail i

Re: [committed] OpenMP: Add interop routines to omp_runtime_api_procname

Now with attached patch … Tobias Burnus wrote: I realized that the attached change (committed asr15-3582-g6291f25631500c) was missing from what I committed in r15-3249-g0beac1db38855e  libgomp: Add interop types and routines to OpenMP's headers and module I also checked the last 5 or so com

[committed] OpenMP: Add interop routines to omp_runtime_api_procname

I realized that the attached change (committed asr15-3582-g6291f25631500c) was missing from what I committed in r15-3249-g0beac1db38855e  libgomp: Add interop types and routines to OpenMP's headers and module I also checked the last 5 or so commits to omp.h.in, but for those routines, we seemed

Re: [PATCH] s390: Fix TF to FPRX2 conversion [PR115860]

On Fri, 2024-08-16 at 09:41 +0200, Stefan Schulze Frielinghaus wrote: > Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1 > survive register allocation.  This in turn leads to wrong register > renaming.  Keeping the current approach would mean we need two insns > for > *tf_to_fpr

[PATCH 2/2] RISC-V: Eliminate latter vsetvl when fused

The current vsetvl pass eliminates a vsetvl instruction when the previous info is "available," but does not when "compatible." This can lead to not only redundancy, but also incorrect behaviors when the previous info happens to be compatible with a later vector instruction, which ends of using the

[PATCH 1/2] RISC-V: Fix vl_used_by_non_rvv_insn logic of vsetvl pass

This patch fixes a bug in the current vsetvl pass. The current pass uses `m_vl` to determine whether the dest operand has been used by non-RVV instructions. However, `m_vl` may have been modified as a result of an `update_avl` call, and thus would be no longer the dest operand of the original ins

Re: [PATCH] Fix wrong code out of NRV + RSO + inlining

On Wed, Sep 11, 2024 at 10:26 AM Eric Botcazou wrote: > > Hi, > > the attached Ada testcase compiled with -O -flto exhibits a wrong code issue > when the 3 optimizations NRV + RSO + inlining are applied to the same call: if > the LHS of the call is marked write-only before inlining, then it will k

[PATCH] Fix wrong code out of NRV + RSO + inlining

Hi, the attached Ada testcase compiled with -O -flto exhibits a wrong code issue when the 3 optimizations NRV + RSO + inlining are applied to the same call: if the LHS of the call is marked write-only before inlining, then it will keep the mark after inlining although it may be read in GIMPLE f

Re: [RFC PATCH] Enable vectorization for unknown tripcount in very cheap cost model but disable epilog vectorization.

On Wed, Sep 11, 2024 at 4:04 PM Richard Biener wrote: > > On Wed, Sep 11, 2024 at 4:17 AM liuhongt wrote: > > > > GCC12 enables vectorization for O2 with very cheap cost model which is > > restricted > > to constant tripcount. The vectorization capacity is very limited w/ > > consideration > >

RE: [PATCH v3 1/2] [APX CFCMOV] Support APX CFCMOV in if_convert pass

> -Original Message- > From: Richard Sandiford > Sent: Friday, September 6, 2024 5:19 PM > To: Kong, Lingling > Cc: gcc-patches@gcc.gnu.org; Jeff Law ; Richard Biener > ; Uros Bizjak ; Hongtao Liu > ; Jakub Jelinek > Subject: Re: [PATCH v3 1/2] [APX CFCMOV] Support APX CFCMOV in if_co

Re: [PATCH] MIPS: Add some floating point instructions support for MIPSr6

在 2024/9/10 17:30, Xi Ruoyao 写道: > On Tue, 2024-09-10 at 16:50 +0800, 梅杰 wrote: >> As for the function `__builtin_rint`, although it exists, however, after >> defining the instruction in `mips.md`, GCC still won't generate `RINT.fmt` >> instruction for MIPS, it generates following code instead: >

Re: [RFC PATCH] Enable vectorization for unknown tripcount in very cheap cost model but disable epilog vectorization.

On Wed, Sep 11, 2024 at 4:17 AM liuhongt wrote: > > GCC12 enables vectorization for O2 with very cheap cost model which is > restricted > to constant tripcount. The vectorization capacity is very limited w/ > consideration > of codesize impact. > > The patch extends the very cheap cost model a l

Re: [PATCH v2 1/2] RISC-V: Fix ICE caused by early ggc_free on DECL for RVV intrinsics in LTO.

On Wed, Sep 11, 2024 at 9:27 AM Jin Ma wrote: > > > > > I'm curious why you ever get a ggc_freed decl here. > > > > > > It seems that the overloaded interface of RVV has been registered > > > repeatedly, resulting > > > in invalid registrations except for the first registration, and these > > >

Re: [PATCH v2 1/2] RISC-V: Fix ICE caused by early ggc_free on DECL for RVV intrinsics in LTO.

> > > I'm curious why you ever get a ggc_freed decl here. > > > > It seems that the overloaded interface of RVV has been registered > > repeatedly, resulting > > in invalid registrations except for the first registration, and these > > invalid registrations > > have been ggc_freed. But anyway, I