Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension

On Wed, Jun 28, 2023 at 8:23 PM Jeff Law wrote: > > > > On 6/28/23 06:39, Christoph Müllner wrote: > > >>> +;; XTheadMemIdx overview: > >>> +;; All peephole passes attempt to improve the operand utilization of > >>> +;; XTheadMemIdx instructions, where one sign or zero extended > >>> +;; register-

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Richard Sandiford writes: > Robin Dapp via Gcc-patches writes: >> Hi Juzhe, >> >> I find the bug description rather confusing. What I can see is that >> the constant in the literal pool is indeed wrong but how would DSE or >> so play a role there? Particularly only for the smaller modes? >> >>

Re: Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Yes. There is a trick fix in RVV. Ideally, each mode should have PRECISION == BITSIZE. However, for RVV, there is a bug which cause incorrect DSE. We have VNx1BI (occupy 1bit), VNx2BI (occupy 2bit), VNx4BI (occupy 4bit), VNx8BI (occupy 8bit), since they are having same BYTESIZE, it cause incorr

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

On Wed, 28 Jun 2023, Jeff Law wrote: > > > On 6/28/23 22:04, Li, Pan2 wrote: > > It seems this patch may result in many test ICE failures on RISC-V backend. > > Could you help to double confirm about it follow the possible reproduce > > steps like blow? Thank you! > I've one ICE due to this chan

[PATCH] c/110454 - ICE with bogus TYPE_PRECISION use

The following sinks TYPE_PRECISION to properly guarded use places. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed as obvious. PR c/110454 gcc/c/ * c-typeck.cc (convert_argument): Sink formal_prec compute to where TYPE_PRECISION is valid to use. * gcc.

[PATCH] middle-end/110461 - pattern applying wrongly to vectors

The following guards a match.pd pattern that wasn't supposed to apply to vectors and thus runs into TYPE_PRECISION checking. For vector support the constant case is lacking and the pattern would have missing optab support checking for the result operation. Bootstrapped and tested on x86_64-unknow

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

I grep'ed a bit and found several more instances of the same pattern which would probably all have to be adjusted (frontend-related mostly but also in native_encode_rtx). Most likely they would all have to be adjusted? > Sorry, only realised later, but: if the precision can cover fewer > bytes t

Re: Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

>> are we absolutely sure this is the only problem we will have >> with precision != bitsize and it is confined to the backend? Yes. >>I would >>not dare to make that call. How does DSE come in here at all as you >>keep mentioning it? I mentioned DSE is because: We have DSE issue before so we u

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

>>> are we absolutely sure this is the only problem we will have >>> with precision != bitsize and it is confined to the backend? > Yes. With vinfo.vector_mode == VNx4SI mask_type = get_mask_type_for_scalar_type (vinfo, int) mask_type is: vector(4) I.e. the precision is 2. This is definitely

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Robin Dapp writes: >> Sorry, only realised later, but: if the precision can cover fewer >> bytes than the bitsize, I suppose there ought to be some zero-byte >> padding at the end as well. > It looks like this problem, and also the padding, has been discussed > before when the precision of VNx1BI

Re: Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Yes, we have no choice since DSE is base on BYTESIZE. So I walk around in RISC-V backend making VNx1BI, VNx2BI, VNx4BI precision different with VNx8BI to prevent incorrect DSE. I think such issue can be addressed when we adjust everything using BITSIZE instead of BYTESIZE but it may change to mu

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

> Yeah, that part is OK, and was the case I was thinking about when > I said OK yesterday. But now that we allow BITSIZE != PRECISION, > it's possible for BITSIZE - PRECISION to be more than a full byte, > in which case the new loop would not initialise every byte of > the mode. Ah, I see, so whe

Re: [PATCH] rs6000, __builtin_set_fpscr_rn add retrun value

Hi Carl, on 2023/6/19 23:57, Carl Love wrote: > GCC maintainers: > > > The GLibC team requested a builtin to replace the mffscrn and mffscrni inline > asm instructions in the GLibC code> Previously there was discussion on adding > builtins for the mffscrn instructions. > > https://gcc.gnu.org

Re: Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

No, I am not saying I want to fix it in RISC-V backend. Actually, if you can quickly land the fix in generic codes and not block of the RISC-V following patches. I am glad to see. Otherwise, I prefer to fix it RISC-V backend for now if it is not a big issue for performance and defer it to GCC-15

Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

Hi! On 2023-06-21T15:58:24+0800, Pan Li via Gcc-patches wrote: > We extend the machine mode from 8 to 16 bits already. But there still > one placing missing from the streamer. It has one hard coded array > for the machine code like size 256. > > In the lto pass, we memset the array by MAX_MACHIN

Re: [PATCH] rs6000: Remove redundant initialization [PR106907]

Hi Jeevitha, on 2023/6/7 13:44, P Jeevitha via Gcc-patches wrote: > PR106907 has few warnings spotted from cppcheck. In that addressing > redundant initialization issue. Here the initialized value of 'new_addr' > was overwritten before it was read. Updated the source by removing the > unnecessary

Re: Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

Not sure what happens you said ICEs all over the place... Actually, even without this patch, current upstream GCC in RISCV port already ICE all over the place: FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-3.c (internal compiler error: tree check: expected none of vector_type, have

RE: [PATCH] PR gcc/110148:Avoid adding loop-carried ops to long chains

> -Original Message- > From: Richard Biener > Sent: Thursday, June 29, 2023 2:42 PM > To: Cui, Lili > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] PR gcc/110148:Avoid adding loop-carried ops to long > chains > > On Thu, Jun 29, 2023 at 3:49 AM Cui, Lili wrote: > > > > From: Lili

Re: Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

Hi! On 2023-06-29T17:33:14+0800, "juzhe.zh...@rivai.ai" wrote: > Not sure what happens you said ICEs all over the place... Ah, sorry for not providing proper context here. My comment was about heterogeneous GCC configurations involving code offloading, like: x86_64 host with GCN, nvptx offload

Re: Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

Ok. Thanks for taking care of it! >> That looks like a different issue, though? Yes, it's different issue and I am trying to fix it in RISC-V backend. Thanks a lot. juzhe.zh...@rivai.ai From: Thomas Schwinge Date: 2023-06-29 17:47 To: juzhe.zh...@rivai.ai CC: pan2...@intel.com; gcc-patches@gc

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

> I think GCN people wanted to make this code work for vectors, the > most obvious local fix is to use element_precision (type) above. > > Note usually vector integer divisions are not a thing so this might > explain why you're seeing this only with RVV? Since nobody else has provided a patch yet

[PATCH] tree-optimization/110460 - fend off vector types from vectorizer

The following makes fending off existing vector types from vectorization also apply to word_mode vector types. I've chosen to add a positive list of allowed scalar types here for clarity. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/110460 * t

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

On Thu, 29 Jun 2023, Robin Dapp wrote: > > I think GCN people wanted to make this code work for vectors, the > > most obvious local fix is to use element_precision (type) above. > > > > Note usually vector integer divisions are not a thing so this might > > explain why you're seeing this only wit

Re: RE: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

Hi， Richi. I tried to debug this ICE: (gdb) call print_gimple_stmt(stdout,stmt,0,0) vect_patt_2876.406_2862 = vect_patt_2877.405_2864 % { 6, ... }; (gdb) p type->type_common.mode $2 = E_VNx4HImode Currently, I have no ideal how to walk around this ICE in RISC-V port. Do you have any suggestions?

Re: [PATCH v2] mips: Fix overaligned function arguments [PR109435]

YunQiang Su 于2023年6月29日周四 14:04写道： > > Jovan Dmitrovic 于2023年6月27日周二 16:54写道： > > > > Hi, > > I am sending a revised patch, now with different tests for N64/N32 and O32 > > ABIs. > > For the O32 ABI, I've skipped the -O0 and -Os pipelines, considering there > > is a > > difference between exact

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

> Currently, I have no ideal how to walk around this ICE in RISC-V port. > Do you have any suggestions? I'm already bootstrapping this patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623184.html I replied to all but it seems you got lost in the thread? Regards Robin

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

Ah, the one sub-thread continued before you were CC'ed. Sorry about that. Regards Robin

Re: Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

Yes. Thanks for taking care of it! juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-06-29 18:07 To: juzhe.zh...@rivai.ai; pan2.li; Richard Biener CC: rdapp.gcc; gcc-patches; jeffreyalaw; kito.cheng Subject: Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs Ah, the one sub-thread continued befo

Re: [PATCH 1/2] Mid engine setup [SU]ABDL

Oluwatamilore Adebayo writes: > From: oluade01 > > This updates vect_recog_abd_pattern to recognize the widening > variant of absolute difference (ABDL, ABDL2). > > gcc/ChangeLog: > > * internal-fn.cc (widening_fn_p, decomposes_to_hilo_fn_p): > Add IFN_VEC_WIDEN_ABD to the switch stat

Re: [PATCH 2/2] AArch64: New RTL for ABDL

Oluwatamilore Adebayo writes: > From: oluade01 > > This patch adds new RTL for ABDL (sabdl, sabdl2, uabdl, uabdl2). > > gcc/ChangeLog: > > * config/aarch64/aarch64-simd.md > (vec_widen_abdl_lo_, vec_widen_abdl_hi_): > Expansions for abd vec widen optabs. > (aarch64_abdl_in

Re: [PATCH] Introduce hardbool attribute for C

On Jun 28, 2023, Qing Zhao wrote: > In summary, Ada’s Boolean variables (whether it’s hardened or not) are > represented as > enumeration types in GNU IR. Not quite. Only boolean types with representation clauses are. Those without (such as Standard.Boolean) are BOOLEAN_TYPEs. But those witho

Re: [PATCH v2] mips: Fix overaligned function arguments [PR109435]

> Ohh, my fault: the `-flto` option should always be skipped, when run test. Right, if tests run with `-flto` option, they will fail. However, I do believe they are run only if LTO support is enabled, that's why my tests all passed without explicitly skipping that option. Your modification looks

[Committed] Add -mmove-max=128 -mstore-max=128 to pieces-memcmp-2.c

Adding -mmove-max=128 and -mstore-max=128 to the dg-options of the recently added gcc.target/i386/pieces-memcmp-2.c avoids changing the intent of this testcase when adding -march=cascadelake to RUNTESTFLAGS. Tested on x86_64-pc-linux-gnu. Committed as obvious. 2023-06-29 Roger Sayle gcc/tes

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

>> Since nobody else has provided a patch yet, is the attached OK as long >> as x86 bootstrap and testsuite are clean? > > Yes. Bootstrap and testsuite are good. Going to commit. Thanks. Regards Robin

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

On Thu, Jun 29, 2023 at 11:10 AM Robin Dapp via Gcc-patches wrote: > > > Yeah, that part is OK, and was the case I was thinking about when > > I said OK yesterday. But now that we allow BITSIZE != PRECISION, > > it's possible for BITSIZE - PRECISION to be more than a full byte, > > in which case

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

> This should probably use GET_MODE_PRECISION as well. > > OK if it bootstraps/tests on both aarch64 and riscv. > > Richard. I found a several other instances, also in the frontends that I'm not exactly sure about. I'm currently testing this but aarch64 bootstrap is still going to take a while,

[PATCH][RFC] target/110456 - avoid loop masking with zero distance dependences

With applying loop masking to epilogues on x86_64 AVX512 we see some significant performance regressions when evaluating SPEC CPU 2017 that are caused by store-to-load forwarding fails across outer loop iterations when the inner loop does not iterate. Consider for (j = 0; j < m; ++j) for (i

Re: [committed] libstdc++: Fix preprocessor conditions for std::from_chars [PR109921]

On Thu, 1 Jun 2023 at 12:05, Jonathan Wakely wrote: > On Thu, 1 Jun 2023 at 10:30, Christophe Lyon via Libstdc++ > wrote: > > > > Hi, > > > > > > On Wed, 31 May 2023 at 14:25, Jonathan Wakely via Gcc-patches < > > gcc-patches@gcc.gnu.org> wrote: > > > > > Tested powerpc64le-linux. Pushed to trun

[PATCH] LoongArch: Fix bug in loongarch_emit_stack_tie [PR110484].

From: Lulu Cheng Which may result in implicit references to $fp when frame_pointer_needed is false, causing regs_ever_live[$fp] to be true when $fp is not explicitly used, resulting in $fp being used as the target replacement register in the rnreg pass. The bug originates from SPEC2017 541.lee

Re: [PATCH][RFC] target/110456 - avoid loop masking with zero distance dependences

Richard Biener writes: > With applying loop masking to epilogues on x86_64 AVX512 we see > some significant performance regressions when evaluating SPEC CPU 2017 > that are caused by store-to-load forwarding fails across outer > loop iterations when the inner loop does not iterate. Consider > >

Re: [PATCH][RFC] target/110456 - avoid loop masking with zero distance dependences

On Thu, 29 Jun 2023, Richard Sandiford wrote: > Richard Biener writes: > > With applying loop masking to epilogues on x86_64 AVX512 we see > > some significant performance regressions when evaluating SPEC CPU 2017 > > that are caused by store-to-load forwarding fails across outer > > loop iterati

Re: [committed] libstdc++: Fix preprocessor conditions for std::from_chars [PR109921]

On Thu, 29 Jun 2023 at 14:50, Jonathan Wakely wrote: > > > On Thu, 1 Jun 2023 at 12:05, Jonathan Wakely > wrote: > >> On Thu, 1 Jun 2023 at 10:30, Christophe Lyon via Libstdc++ >> wrote: >> > >> > Hi, >> > >> > >> > On Wed, 31 May 2023 at 14:25, Jonathan Wakely via Gcc-patches < >> > gcc-patche

Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors

On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote: > > > > > > From: Richard Biener > Date: Tuesday, June 27, 2023 at 12:58 PM > To: Tejas Belagod > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors > > On Tue, Jun 27, 2023 at 8:30 AM Tejas Belago

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Hi Robin: > diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc > index 52d7626e92e..14d419c2013 100644 > --- a/gcc/lto/lto-lang.cc > +++ b/gcc/lto/lto-lang.cc > @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p) >else if (GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL >

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Kito Cheng writes: > Hi Robin: > >> diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc >> index 52d7626e92e..14d419c2013 100644 >> --- a/gcc/lto/lto-lang.cc >> +++ b/gcc/lto/lto-lang.cc >> @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p) >>else if (GET_MODE_CLASS

Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension

On 6/29/23 01:39, Christoph Müllner wrote: On Wed, Jun 28, 2023 at 8:23 PM Jeff Law wrote: On 6/28/23 06:39, Christoph Müllner wrote: +;; XTheadMemIdx overview: +;; All peephole passes attempt to improve the operand utilization of +;; XTheadMemIdx instructions, where one sign or zero ex

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

>> Hi Robin: >> >>> diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc >>> index 52d7626e92e..14d419c2013 100644 >>> --- a/gcc/lto/lto-lang.cc >>> +++ b/gcc/lto/lto-lang.cc >>> @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p) >>>else if (GET_MODE_CLASS (mode) == M

Re: [PATCH] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

Hi Juzhe, just looking at the documentation changes. > +@cindex @code{len_mask_gather_load@var{m}@var{n}} instruction pattern > +@item @samp{len_mask_gather_load@var{m}@var{n}} > +Like @samp{gather_load@var{m}@var{n}}, but takes an extra len operand > +as operand 5 and an extra mask operand as op

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

On 6/29/23 02:11, Richard Biener wrote: On Wed, 28 Jun 2023, Jeff Law wrote: On 6/28/23 22:04, Li, Pan2 wrote: It seems this patch may result in many test ICE failures on RISC-V backend. Could you help to double confirm about it follow the possible reproduce steps like blow? Thank you! I

Re: [PATCH] Introduce hardbool attribute for C

Hi, ALexandre, Thank you for the explanation. I am now clear with the interaction between hardbool and -ftrivial-auto-var-init, and also agree that clarifying the documentation on their interaction is good enough. Qing > On Jun 29, 2023, at 6:30 AM, Alexandre Oliva wrote: > > On Jun 28, 2023

[committed] libstdc++: Fix src/c++20/tzdb.cc for non-constexpr std::mutex

This build failure for riscv32-esp-elf was "reported" on the gcc-help list: https://gcc.gnu.org/pipermail/gcc-help/2023-June/142641.html Tested x86_64-linux. Pushed to trunk. -- >8 -- Building libstdc++ reportedly fails for targets without lock-free std::atomic which don't define __GTHREAD_MUTEX

[PATCH] c++: NSDMI instantiation during overload resolution [PR110468]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13/12? -- >8 -- Here we find ourselves instantiating the NSDMI for A<1>::m when computing argument conversions during overload resolution, and thus tf_conv is set. This causes mark_used for the constructor used in the

[PATCH] c++: unpropagated CONSTRUCTOR_MUTABLE_POISON [PR110463]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13? -- >8 -- cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding a CONSTRUCTOR initializer, which for the below testcase causes us to fail to reject a mutable member access of a constexpr variabl

[committed] libstdc++: Do not use off64_t in calls to copy_file_range [PR110462]

Tested x86_64-linux. Pushed to trunk. -- >8 -- Although the copy_file_range(2) man page shows the arguments as off64_t* that is not portable. For musl there is no off64_t type, as off_t is always 64-bit. Use the loff_t type which is always 64-bit even if off_t isn't. We could just use off_t becau

[committed] cselib+expr+bitmap: Change return type of predicate functions from int to bool

gcc/ChangeLog: * cselib.h (rtx_equal_for_cselib_1): Change return type from int to bool. (references_value_p): Ditto. (rtx_equal_for_cselib_p): Ditto. * expr.h (can_store_by_pieces): Ditto. (try_casesi): Ditto. (try_tablejump): Ditto. (safe_from_p): Ditto. * sbi

Re: [PATCH] c++: unpropagated CONSTRUCTOR_MUTABLE_POISON [PR110463]

On Thu, Jun 29, 2023 at 11:22:55AM -0400, Patrick Palka via Gcc-patches wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk/13? > > -- >8 -- > > cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding > a CONSTRUCTOR initializer, which for

Re: [PATCH] configure: Implement --enable-host-bind-now

Hi, On Tue, Jun 27 2023, Marek Polacek wrote: > On Tue, Jun 27, 2023 at 01:39:16PM +0200, Martin Jambor wrote: >> Hello, >> >> On Tue, May 16 2023, Marek Polacek via Gcc-patches wrote: >> > As promised in the --enable-host-pie patch, this patch adds another >> > configure option, --enable-host-bi

Re: [PATCH] configure: Implement --enable-host-bind-now

On Thu, Jun 29, 2023 at 05:58:22PM +0200, Martin Jambor wrote: > Hi, > > On Tue, Jun 27 2023, Marek Polacek wrote: > > On Tue, Jun 27, 2023 at 01:39:16PM +0200, Martin Jambor wrote: > >> Hello, > >> > >> On Tue, May 16 2023, Marek Polacek via Gcc-patches wrote: > >> > As promised in the --enable-

[COMMITTED] Move maybe_set_nonzero_bits() to its only user.

gcc/ChangeLog: * tree-vrp.cc (maybe_set_nonzero_bits): Move from here... * tree-ssa-dom.cc (maybe_set_nonzero_bits): ...to here. * tree-vrp.h (maybe_set_nonzero_bits): Remove. --- gcc/tree-ssa-dom.cc | 65 + gcc/tree-vrp.cc |

[COMMITTED] Tidy up the range normalization code.

There's a few spots where a range is being altered in-place, but we fail to call normalize the range. This patch makes sure we always call normalize_kind(), and that normalize_kind in turn, calls verify_range to make sure verything is canonical. gcc/ChangeLog: * value-range.cc (frange::s

Re: [PATCH] Relax type-printer regexp in libstdc++ test suite

> Jonathan Wakely writes: > Looks good. OK for trunk, and OK to backport after some soak time on trunk. > Thanks. AdaCore doesn't need a backport of this, and I don't think it's extremely important; so unless you want me to do it, I don't plan to. I did check it in on trunk earlier today.

Re: [PATCH] c++: Fix ICE with parameter pack of decltype(auto) [PR103497]

On 6/24/23 09:24, Nathaniel Shead wrote: On Fri, Jun 23, 2023 at 11:59:51AM -0400, Patrick Palka wrote: Hi, On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote: Bootstrapped and tested on x86_64-pc-linux-gnu. -- 8< -- This patch raises an error early when the decltype(auto) specifier

Re: [PATCH] c++: NSDMI instantiation during overload resolution [PR110468]

On 6/29/23 11:22, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13/12? OK. -- >8 -- Here we find ourselves instantiating the NSDMI for A<1>::m when computing argument conversions during overload resolution, and thus tf_conv is set. This

Re: [PATCH] c++: unpropagated CONSTRUCTOR_MUTABLE_POISON [PR110463]

On 6/29/23 11:36, Marek Polacek wrote: On Thu, Jun 29, 2023 at 11:22:55AM -0400, Patrick Palka via Gcc-patches wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/13? -- >8 -- cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding a CONSTRU

Re: [PATCH] Relax type-printer regexp in libstdc++ test suite

On Thu, 29 Jun 2023 at 17:59, Tom Tromey wrote: > > Jonathan Wakely writes: > > > Looks good. OK for trunk, and OK to backport after some soak time on > trunk. Thanks. > > AdaCore doesn't need a backport of this, and I don't think it's > extremely important; so unless you want me to do it, I

Re: [PATCH] aarch64: Remove architecture dependencies from intrinsics

On Tue, Jun 27, 2023 at 07:23:32AM +0100, Richard Sandiford wrote: > Andrew Carlotti via Gcc-patches writes: > > Many intrinsics currently depend on both an architecture version and a > > feature, despite the corresponding instructions being available within > > GCC at lower architecture versions.

Re: [PATCH] analyzer: Fix regression bug after r14-1632-g9589a46ddadc8b [PR110198]

From: benjamin priour See below formatting updates on my patch. In mail https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623140.html, David Malcolm says regtesting failed for him. So I did it once more this morning rebased on fresh trunk dc93a0f633b and target x86_64-linux-gnu, the output was

[PATCH] testsuite: Use -fno-report-bug in gcc.dg/plugin/

Certain downstream compilers (for example, in Fedora) default to -freport-bug. The extra output breaks the following tests. We can use -fno-report-bug to fix that. Patch verified with: $ make check RUNTESTFLAGS='--target_board=unix\{,-freport-bug\} plugin.exp' Tested x86_64-pc-linux-gnu, ok fo

[PATCH] i386: add -fno-stack-protector to two tests

These tests fail when the testsuite is executed with -fstack-protector-strong. To avoid this, this patch adds -fno-stack-protector to dg-options. Tested on x86_64-pc-linux-gnu, ok for trunk? gcc/testsuite/ChangeLog: * gcc.target/i386/pr104610.c: Use -fno-stack-protector. * gcc.ta

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > These tests fail when the testsuite is executed with -fstack- > protector-strong. > To avoid this, this patch adds -fno-stack-protector to dg-options. > > Tested on x86_64-pc-linux-gnu, ok for trunk? LGTM, we've noticed the

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Thu, Jun 29, 2023 at 04:01:20PM -0400, Marek Polacek via Gcc-patches wrote: > These tests fail when the testsuite is executed with -fstack-protector-strong. > To avoid this, this patch adds -fno-stack-protector to dg-options. > > Tested on x86_64-pc-linux-gnu, ok for trunk? > > gcc/testsuite/C

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > These tests fail when the testsuite is executed with -fstack- > > protector-strong. > > To avoid this, this patch adds -fno-stack-protector to dg-options. > > > > Teste

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, Jun 30, 2023 at 04:11:44AM +0800, Xi Ruoyao via Gcc-patches wrote: > On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > > These tests fail when the testsuite is executed with -fstack- > > > protector-strong. >

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, Jun 30, 2023 at 04:11:44AM +0800, Xi Ruoyao wrote: > On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > > These tests fail when the testsuite is executed with -fstack- > > > protector-strong. > > > To avoid thi

Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

Hi! On 2023-06-29T11:29:57+0200, I wrote: > On 2023-06-21T15:58:24+0800, Pan Li via Gcc-patches > wrote: >> We extend the machine mode from 8 to 16 bits already. But there still >> one placing missing from the streamer. It has one hard coded array >> for the machine code like size 256. >> >> In

Re: [PATCH] testsuite: Use -fno-report-bug in gcc.dg/plugin/

On Thu, 2023-06-29 at 15:03 -0400, Marek Polacek wrote: > Certain downstream compilers (for example, in Fedora) default to > -freport-bug.  The extra output breaks the following tests.  We can > use > -fno-report-bug to fix that.  Patch verified with: > > $ make check RUNTESTFLAGS='--target_board=

Re: [PATCH] analyzer: Fix regression bug after r14-1632-g9589a46ddadc8b [PR110198]

On Thu, 2023-06-29 at 20:45 +0200, priour...@gmail.com wrote: > From: benjamin priour > > See below formatting updates on my patch. > In mail > https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623140.html, > David Malcolm says regtesting failed for him. > > So I did it once more this morning

Extend ipa-fnsummary to skip __builtin_expect

Compute ipa-predicates for conditionals involving __builtin_expect_p std::vector allocator looks as follows: __attribute__((nodiscard)) struct pair * std::__new_allocator >::allocate (struct __new_allocator * const this, size_type __n, const void * D.27753) { bool _1; long int _2; long in

Re: [PATCH v1] RISC-V: Refactor vxrm_mode attr for type attr equal

On 6/29/23 00:00, pan2...@intel.com wrote: From: Pan Li This patch would like to refactor the vxrm_mode attr for duplicated eq_attr condition. The common condition of attr is extraced to one place instead of many places. Signed-off-by: Pan Li gcc/ChangeLog: * config/riscv/vector.

Re: [PATCH] rs6000: Update the vsx-vector-6.* tests.

Kewen: On Wed, 2023-06-28 at 16:35 +0800, Kewen.Lin wrote: > > Yea, I was going with a runnable test and didn't include the > > instruction counts. Added back in. Rather then doing by processor > > version (P8, P9, P10) I was able to do it by BE/LE. The > > instruction > > counts were the same

Re: [PATCH 2/19][front-end] C/C++ front-end: add pragma GCC novector

On 6/28/23 09:41, Tamar Christina wrote: Hi All, FORTRAN currently has a pragma NOVECTOR for indicating that vectorization should not be applied to a particular loop. ICC/ICX also has such a pragma for C and C++ called #pragma novector. As part of this patch series I need a way to easily turn

Re: [PATCH] c++: fix up caching of level lowered ttps

On 6/1/23 17:42, Patrick Palka wrote: Due to level/depth mismatches between the template parameters of a level lowered ttp and the original ttp, the ttp comparison check added by r14-418-g0bc2a1dc327af9 never actually holds outside of erroneous cases. Moreover, it'd be good to cache the overall T

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/28/23 16:00, 钟居哲 wrote: You can see here: https://godbolt.org/z/d78646hWb The first case can't genreate vfwmul.vv but second case succeed. Failed to match this instruction: (set (reg:VNx2DF 150 [ vect__11.50 ])     (if_then_else:VNx2DF (unspec:VNx2BI

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

>> Right now I don't see a need for this patch. No, we need this patch. With this patch, this following case can be combine into vfwmul.vv: #define TEST_TYPE(TYPE1, TYPE2)\ __attribute__ ((noipa)) void vwadd_##TYPE1_##TYPE2 (

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

Or do you have better solution to make the case succeed to combine into vfwmul? I am ok with any solution. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-06-30 06:59 To: 钟居哲; gcc-patches CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combin

[PATCH ver 3] rs6000: Update the vsx-vector-6.* tests.

GCC maintainers: Ver 3. Added __attribute__ ((noipa)) to the test files. Changed some of the scan-assembler-times checks to cover multiple similar instructions. Change the function check macro to a macro to generate a function to do the test and check the results. Retested on the various proce

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/28/23 16:00, 钟居哲 wrote: You can see here: https://godbolt.org/z/d78646hWb So just to be explicit, I see no difference with that test before/after your proposed change. Nor would I expect one based on my understanding of the patch. The explicit conve

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/28/23 16:00, 钟居哲 wrote: You can see here: https://godbolt.org/z/d78646hWb You patch doesn't help that code and your patch is a result of fundamentally misunderstanding combine's capabilities AFAICT. Jeff

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

On 6/28/23 16:56, 钟居哲 wrote: juzhe.zh...@rivai.ai *From:* Jeff Law *Date:* 2023-06-29 06:43 *To:* 钟居哲 ; gcc-patches

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 6/29/23 17:46, juzhe.zhong wrote: You should try the example check the codegen before and after the patch. You will understand it. I've already done that. It makes _no_ difference on the godbold example. Jeff

Re: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

Hi, Jeff. That's odd. I think maybe you should first clean up your environment ? Or you didn't build up the toolchain correctly with this patch? Compile option: --param=riscv-autovec-preference=scalable -O3 -ffast-math Before this patch: https://godbolt.org/z/Y5d44WMqs fail.s: lw t5,0(sp) ble

Re: Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

No, reduction patterns won't help. As I said in vfwmul patch. You should make sure your environment is working then try again. Thanks. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-06-30 07:43 To: 钟居哲; gcc-patches CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc Subject: Re: [PATCH] R

Re: Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

Thanks a lot! Really appreciate your help ! That's really helpful for RVV (RISC-V vector). Could you merge your patch after you tested? Thanks. juzhe.zh...@rivai.ai From: Thomas Schwinge Date: 2023-06-30 04:14 To: Pan Li; gcc-patches@gcc.gnu.org; Richard Biener; Jakub Jelinek CC: juzhe.zh...@

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

On 6/29/23 19:14, juzhe.zh...@rivai.ai wrote: No, reduction patterns won't help. As I said in vfwmul patch. You should make sure your environment is working then try again. I've triple checked this already. I checked it again and your patch does not impact behavior, nor should it. I chec

Re: Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

>> I've triple checked this already. You mean you still didn't see vfwmul.vv ? That's odd. Let's wait for kito or Robin test this patch. Then, I believe they will know what I am saying. >> I would strongly suggest looking at a dependency height reduction >> pattern if you want to optimize that co

RE: Re: [PATCH v3] Streamer: Fix out of range memory access of machine mode

That’s very cool, thanks Thomas for help! Let’s wait the AMD test running result for the final version of the patch. Pan From: juzhe.zh...@rivai.ai Sent: Friday, June 30, 2023 9:27 AM To: Thomas Schwinge ; Li, Pan2 ; gcc-patches ; rguenther ; jakub Cc: Robin Dapp ; jeffreyalaw ; Wang, Yanzh

Re: Re: [PATCH] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

Thanks for the comments. I will fix doc's description as you suggested. I personally prefer **NOT** to include BIAS in the gather/scatter since I don't known how it will be used. Let's wait for Richi or Richard more comments. Thanks. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-06-29 2

[PATCH v1 0/6] Add Loongson SX/ASX instruction support to LoongArch target.

These patches add the Loongson SX/ASX instruction support to the LoongArch target, and can be utilized by using the new "-mlsx" and "-mlasx" option. Patches are bootstrapped and tested on loongarch64-linux-gnu target. Lulu Cheng (6): LoongArch: Added Loongson SX vector directive compilation fra

[PATCH v1 1/6] LoongArch: Added Loongson SX vector directive compilation framework.

From: Lulu Cheng gcc/ChangeLog: * config/loongarch/genopts/loongarch-strings: Added compilation framework. * config/loongarch/genopts/loongarch.opt.in: Ditto. * config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto. * config/loongarch/loongarch-def.

[PATCH v1 4/6] LoongArch: Added Loongson ASX vector directive compilation framework.

From: Lulu Cheng gcc/ChangeLog: * config/loongarch/genopts/loongarch-strings: Added compilation framework. * config/loongarch/genopts/loongarch.opt.in: Ditto. * config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins): Ditto. * config/loongarch/loongarch-def.

  1   2   >