[PATCH v10] RISC-V: Refactor requirement of ZVFH and ZVFHMIN.

From: Pan Li This patch would like to refactor the requirement of both the ZVFH and ZVFHMIN. By default, the ZVFHMIN will enable FP16 for all the iterators of RVV. And then the ZVFH will leverage one define attr as the gate for FP16 supported or not. Please note the ZVFH will cover the ZVFHMIN i

RE: RE: [PATCH v9] RISC-V: Refactor requirement of ZVFH and ZVFHMIN.

Thanks Juzhe and Kito for reviewing, update the PATCH v10 as below. https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621104.html Pan -Original Message- From: Gcc-patches On Behalf Of Li, Pan2 via Gcc-patches Sent: Friday, June 9, 2023 2:41 PM To: juzhe.zh...@rivai.ai; gcc-patches C

Re: [PATCH v10] RISC-V: Refactor requirement of ZVFH and ZVFHMIN.

LGTM. juzhe.zh...@rivai.ai From: pan2.li Date: 2023-06-09 15:07 To: gcc-patches CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v10] RISC-V: Refactor requirement of ZVFH and ZVFHMIN. From: Pan Li This patch would like to refactor the requirement o

[PATCH] middle-end/110182 - TYPE_PRECISION on VECTOR_TYPE causes wrong-code

When folding two conversions in a row we use TYPE_PRECISION but that's invalid for VECTOR_TYPE. The following fixes this by using element_precision instead. Bootstrap and regtest running on x86_64-unknown-linux-gnu. * match.pd (two conversions in a row): Use element_precision to

[PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

The following makes sure that using TYPE_PRECISION on VECTOR_TYPE ICEs when tree checking is enabled. This should avoid wrong-code in cases like PR110182 and instead ICE. Bootstrap and regtest pending on x86_64-unknown-linux-gnu, I guess there will be some fallout of such change ... * tr

[PATCH v1] RISC-V: Fix one warning of frm enum.

From: Pan Li This patch would like to fix one warning similar as below, and add the link for where the values comes from. ./gcc/config/riscv/riscv-protos.h:260:13: warning: binary constants are a C++14 feature or GCC extension FRM_RNE = 0b000, ^ Signed-off-by: Pan

Re: [PATCH] Make sure SCALAR_INT_MODE_P before invoke try_const_anchors

On Fri, 9 Jun 2023, Jiufu Guo wrote: > Hi, > > As checking the code, there is a "gcc_assert (SCALAR_INT_MODE_P (mode))" > in "try_const_anchors". > This assert seems correct because the function try_const_anchors cares > about integer values currently, and modes other than SCALAR_INT_MODE_P > are

[committed] fortran: Fix ICE on pr96024.f90 on big-endian hosts [PR96024]

Hi! The pr96024.f90 testcase ICEs on big-endian hosts. The problem is that length->val.integer is accessed after checking length->expr_type == EXPR_CONSTANT, but it is a CHARACTER constant which uses length->val.character union member instead and on big-endian we end up reading constant 0x100

Re: [PATCH v1] RISC-V: Fix one warning of frm enum.

Ok. juzhe.zh...@rivai.ai From: pan2.li Date: 2023-06-09 15:53 To: gcc-patches CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng Subject: [PATCH v1] RISC-V: Fix one warning of frm enum. From: Pan Li This patch would like to fix one warning similar as below, and add

Re: [PATCH v1] RISC-V: Fix one warning of frm enum.

Lgtm juzhe.zh...@rivai.ai 於 2023年6月9日 週五，16:08寫道： > Ok. > > > > juzhe.zh...@rivai.ai > > From: pan2.li > Date: 2023-06-09 15:53 > To: gcc-patches > CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; > kito.cheng > Subject: [PATCH v1] RISC-V: Fix one warning of frm enum. > From: Pan

Re: [PATCH V5] VECT: Add SELECT_VL support

On Thu, 8 Jun 2023, juzhe.zh...@rivai.ai wrote: > From: Ju-Zhe Zhong > > Co-authored-by: Richard Sandiford > Co-authored-by: Richard Biener > > This patch address comments from Richard && Richi and rebase to trunk. > > This patch is adding SELECT_VL middle-end support > allow target have targ

RE: [PATCH v1] RISC-V: Fix one warning of frm enum.

Committed, thanks Kito and Juzhe. Pan From: Kito Cheng Sent: Friday, June 9, 2023 4:11 PM To: juzhe.zh...@rivai.ai Cc: Robin Dapp ; gcc-patches ; jeffreyalaw ; Li, Pan2 ; Wang, Yanzhang Subject: Re: [PATCH v1] RISC-V: Fix one warning of frm enum. Lgtm juzhe.zh...@rivai.ai

Re: Re: [PATCH V5] VECT: Add SELECT_VL support

Hi, Richi. Thanks for comments. >>this is in a if (j == 0) branch, please put the assert into the >>else {} block of it instead. You still run the 'bump' computation >>before the loop, so if you intend to never handle j != 0 you could >>put it there, too. But at least avoid calling >>vect_get_d

Re: [PATCH] Make sure SCALAR_INT_MODE_P before invoke try_const_anchors

Hi, On 2023-06-09 16:00, Richard Biener wrote: On Fri, 9 Jun 2023, Jiufu Guo wrote: Hi, As checking the code, there is a "gcc_assert (SCALAR_INT_MODE_P (mode))" in "try_const_anchors". This assert seems correct because the function try_const_anchors cares about integer values currently, and

Re: [PATCH v10] RISC-V: Refactor requirement of ZVFH and ZVFHMIN.

lgtm too, thanks :) On Fri, Jun 9, 2023 at 3:15 PM juzhe.zh...@rivai.ai wrote: > > LGTM. > > > > juzhe.zh...@rivai.ai > > From: pan2.li > Date: 2023-06-09 15:07 > To: gcc-patches > CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng > Subject: [PATCH v10] RISC-V: Refactor

RE: [PATCH v10] RISC-V: Refactor requirement of ZVFH and ZVFHMIN.

Committed, thanks Juzhe and Kito. Pan -Original Message- From: Kito Cheng Sent: Friday, June 9, 2023 4:28 PM To: juzhe.zh...@rivai.ai Cc: Li, Pan2 ; gcc-patches ; Robin Dapp ; jeffreyalaw ; Wang, Yanzhang Subject: Re: [PATCH v10] RISC-V: Refactor requirement of ZVFH and ZVFHMIN. lgt

Re: [PATCH] Make sure SCALAR_INT_MODE_P before invoke try_const_anchors

guojiufu writes: > Hi, > > On 2023-06-09 16:00, Richard Biener wrote: >> On Fri, 9 Jun 2023, Jiufu Guo wrote: >> >>> Hi, >>> >>> As checking the code, there is a "gcc_assert (SCALAR_INT_MODE_P >>> (mode))" >>> in "try_const_anchors". >>> This assert seems correct because the function try_const_

Re: [COMMITTED 2/4] - Remove tree_code from range-operator.

On 6/8/23 20:57, Andrew MacLeod wrote: Range_operator had a tree code added last release to facilitate bitmask operations.  This was intended to be a temporary change until we could figure out something more strategic going forward. This patch removes the tree_code and replaces it with a vi

[PATCH V6] VECT: Add SELECT_VL support

From: Ju-Zhe Zhong Co-authored-by: Richard Sandiford Co-authored-by: Richard Biener This patch address comments from Richard && Richi and rebase to trunk. This patch is adding SELECT_VL middle-end support allow target have target dependent optimization in case of length calculation. This patc

Re: Re: [PATCH V5] VECT: Add SELECT_VL support

Hi, Richi. I have fixed by following your suggestions Could you take a look at it? V6 patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621122.html Thanks. juzhe.zh...@rivai.ai From: Richard Biener Date: 2023-06-09 16:13 To: Ju-Zhe Zhong CC: gcc-patches; richard.sandiford Subject: R

Re: [PATCH] Add COMPLEX_VECTOR_INT modes

On 07/06/2023 20:42, Richard Sandiford wrote: I don't know if this helps (probably not), but we have a similar situation on AArch64: a 64-bit mode like V8QI can be doubled to a 128-bit vector or to a pair of 64-bit vectors. We used V16QI for the former and "V2x8QI" for the latter. V2x8QI is for

Re: [PATCH V2] Optimize '(X - N * M) / N' to 'X / N - M' if valid

On Wed, 7 Jun 2023, Jiufu Guo wrote: > Hi, > > This patch tries to optimize "(X - N * M) / N" to "X / N - M". > For C code, "/" towards zero (trunc_div), and "X - N * M" maybe > wrap/overflow/underflow. So, it is valid that "X - N * M" does > not cross zero and does not wrap/overflow/underflow. >

Re: [PATCH] Make sure SCALAR_INT_MODE_P before invoke try_const_anchors

On Fri, 9 Jun 2023, Richard Sandiford wrote: > guojiufu writes: > > Hi, > > > > On 2023-06-09 16:00, Richard Biener wrote: > >> On Fri, 9 Jun 2023, Jiufu Guo wrote: > >> > >>> Hi, > >>> > >>> As checking the code, there is a "gcc_assert (SCALAR_INT_MODE_P > >>> (mode))" > >>> in "try_const_anc

[committed] libstdc++: Improve tests for emplace member of sequence containers

I'm fairly confident these emplace member functions work correctly, but it's still nice to actually test them! Tested powerpc64le-linux. Pushed to trunk. -- >8 -- Our existing tests for std::deque::emplace, std::list::emplace and std::vector::emplace are poor. We only have compile tests for PR 5

Re: [PATCH] testsuite: fix the condition bug in tsvc s176

On Thu, Jun 8, 2023 at 1:24 PM Lehua Ding wrote: > > Hi, > > This patch fixes the problem that the loop in the tsvc s176 function is > optimized and removed because `iterations/LEN_1D` is 0 (where iterations > is set to 1, LEN_1D is set to 32000 in tsvc.h). > > This testcase passed on x86 and

Re: [committed] libstdc++: Fix code size regressions in std::vector [PR110060]

On Thu, Jun 8, 2023 at 11:15 AM Jakub Jelinek via Gcc-patches wrote: > > On Thu, Jun 08, 2023 at 10:05:43AM +0100, Jonathan Wakely via Gcc-patches > wrote: > > > Looking at assembly, one of the differences I see is that the "after" > > > version has calls to realloc_insert(), while "before" versi

Re: [PATCH] Add COMPLEX_VECTOR_INT modes

Andrew Stubbs writes: > On 07/06/2023 20:42, Richard Sandiford wrote: >> I don't know if this helps (probably not), but we have a similar >> situation on AArch64: a 64-bit mode like V8QI can be doubled to a >> 128-bit vector or to a pair of 64-bit vectors. We used V16QI for >> the former and "V2x

Re: [PATCH RFC] c++: use __cxa_call_terminate for MUST_NOT_THROW [PR97720]

On Thu, Jun 8, 2023 at 3:14 PM Jonathan Wakely via Gcc-patches wrote: > > On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote: > > > > > > > On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ < > > libstd...@gcc.gnu.org> wrote: > > > >> Middle-end folks: any thoughts about how best to make

Re: [PATCH] fix frange_nextafter odr violation

On Thu, Jun 8, 2023 at 4:38 PM Alexandre Oliva via Gcc-patches wrote: > > > C++ requires inline functions to be declared inline and defined in > every translation unit that uses them. frange_nextafter is used in > gimple-range-op.cc but it's only defined as inline in > range-op-float.cc. Drop th

Re: [PATCH] doc: Clarification for -Wmissing-field-initializers

On Thu, Jun 8, 2023 at 7:57 PM Marek Polacek via Gcc-patches wrote: > > The manual is incorrect in saying that the option does not warn > about designated initializers, which it does in C++. Whether the > divergence in behavior is desirable is another thing, but let's > at least make the manual m

Re: [PATCH] MATCH: Fix zero_one_valued_p not to match signed 1 bit integers

On Fri, Jun 9, 2023 at 3:48 AM Andrew Pinski via Gcc-patches wrote: > > So for the attached testcase, we assumed that zero_one_valued_p would > be the value [0,1] but currently zero_one_valued_p matches also > signed 1 bit integers. > This changes that not to match that and fixes the 2 new testcas

Re: [PATCH RFC] c++: use __cxa_call_terminate for MUST_NOT_THROW [PR97720]

On Fri, 9 Jun 2023 at 10:03, Richard Biener wrote: > On Thu, Jun 8, 2023 at 3:14 PM Jonathan Wakely via Gcc-patches > wrote: > > > > On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote: > > > > > > > > > > > On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ < > > > libstd...@gcc.gnu.org>

Re: [PATCH RFC] c++: use __cxa_call_terminate for MUST_NOT_THROW [PR97720]

On Fri, Jun 09, 2023 at 11:02:48AM +0200, Richard Biener via Gcc-patches wrote: > > Currently both gcc-13 and trunk are at the same library version, > > libstdc++.so.6.0.32 > > > > But with this addition to trunk we need to bump that .32 to .33, meaning > > that gcc-13 and trunk diverge. If we want

Re: [PATCH] Make sure SCALAR_INT_MODE_P before invoke try_const_anchors

Hi, Richard Biener writes: > On Fri, 9 Jun 2023, Richard Sandiford wrote: > >> guojiufu writes: >> > Hi, >> > >> > On 2023-06-09 16:00, Richard Biener wrote: >> >> On Fri, 9 Jun 2023, Jiufu Guo wrote: >> >> >> >>> Hi, >> >>> >> >>> As checking the code, there is a "gcc_assert (SCALAR_INT_MO

Re: [PATCH] MATCH: Fix zero_one_valued_p not to match signed 1 bit integers

On Fri, Jun 09, 2023 at 11:06:04AM +0200, Richard Biener via Gcc-patches wrote: > On Fri, Jun 9, 2023 at 3:48 AM Andrew Pinski via Gcc-patches > wrote: > > > > So for the attached testcase, we assumed that zero_one_valued_p would > > be the value [0,1] but currently zero_one_valued_p matches also

Re: [PATCH V6] VECT: Add SELECT_VL support

Just finish running Boostrap on X86 has passed. Ok for trunk? Thanks. juzhe.zh...@rivai.ai From: juzhe.zhong Date: 2023-06-09 16:39 To: gcc-patches CC: richard.sandiford; rguenther; Ju-Zhe Zhong Subject: [PATCH V6] VECT: Add SELECT_VL support From: Ju-Zhe Zhong Co-authored-by: Richard Sandi

Re: [PATCH] Add COMPLEX_VECTOR_INT modes

On 09/06/2023 10:02, Richard Sandiford wrote: Andrew Stubbs writes: On 07/06/2023 20:42, Richard Sandiford wrote: I don't know if this helps (probably not), but we have a similar situation on AArch64: a 64-bit mode like V8QI can be doubled to a 128-bit vector or to a pair of 64-bit vectors. W

Re: [PATCH v4] RISC-V: Add vector psabi checking.

Hmmm, I still saw some fail on testsuite after applying this patch, most are because the testcase has used vector type as argument or return value, but .. vector-abi-1.c should not fail I think? For other fails, I would suggest you could just add -Wno-psabi to rvv.exp === gcc: Une

Re: [PATCH] testsuite: fix the condition bug in tsvc s176

> It's odd that the checksum doesn't depend on the number of iterations done ... This is because the difference between the calculated result (32063.902344) and the expected result (32000.00) is small. The current check is that the result is considered correct as long as the `value/expected`

[PATCH] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

From: Juzhe-Zhong This patch is to rework Phase 5 && Phase 6 of VSETVL PASS since Phase 5 && Phase 6 are quite messy and cause some bugs discovered by my downstream auto-vectorization test-generator. Before this patch. Phase 5 is cleanup_insns is the function remove AVL operand dependency fro

[PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

From: Juzhe-Zhong This patch is to rework Phase 5 && Phase 6 of VSETVL PASS since Phase 5 && Phase 6 are quite messy and cause some bugs discovered by my downstream auto-vectorization test-generator. Before this patch. Phase 5 is cleanup_insns is the function remove AVL operand dependency fro

Re: [PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

Thankful you send this before weekend, I could run the fuzzy testing during this weekend :P On Fri, Jun 9, 2023 at 6:41 PM wrote: > > From: Juzhe-Zhong > > This patch is to rework Phase 5 && Phase 6 of VSETVL PASS since Phase 5 && > Phase 6 > are quite messy and cause some bugs discovered by my

Re: Re: [PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

This patch removed 2nd time initialization of RTL_SSA which is the approach we both hate. juzhe.zh...@rivai.ai From: Kito Cheng Date: 2023-06-09 18:45 To: juzhe.zhong CC: gcc-patches; kito.cheng; palmer; palmer; jeffreyalaw; rdapp.gcc; pan2.li Subject: Re: [PATCH V2] RISC-V: Rework Phase 5 &&

Re: [PATCH] Make sure SCALAR_INT_MODE_P before invoke try_const_anchors

On Fri, 9 Jun 2023, Jiufu Guo wrote: > > Hi, > > Richard Biener writes: > > > On Fri, 9 Jun 2023, Richard Sandiford wrote: > > > >> guojiufu writes: > >> > Hi, > >> > > >> > On 2023-06-09 16:00, Richard Biener wrote: > >> >> On Fri, 9 Jun 2023, Jiufu Guo wrote: > >> >> > >> >>> Hi, > >> >>>

Re: [PATCH V6] VECT: Add SELECT_VL support

On Fri, 9 Jun 2023, juzhe.zh...@rivai.ai wrote: > From: Ju-Zhe Zhong > > Co-authored-by: Richard Sandiford > Co-authored-by: Richard Biener > > This patch address comments from Richard && Richi and rebase to trunk. > > This patch is adding SELECT_VL middle-end support > allow target have targ

Re: Re: [PATCH V6] VECT: Add SELECT_VL support

Thanks, Richi. Should I wait for Richard ACK gain ? Since the last email of this patch, he just asked me to adjust comment no codes change. I am not sure whether he is ok. Thanks. juzhe.zh...@rivai.ai From: Richard Biener Date: 2023-06-09 19:02 To: Ju-Zhe Zhong CC: gcc-patches; richard.sand

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

On Fri, 9 Jun 2023, Richard Biener wrote: > The following makes sure that using TYPE_PRECISION on VECTOR_TYPE > ICEs when tree checking is enabled. This should avoid wrong-code > in cases like PR110182 and instead ICE. > > Bootstrap and regtest pending on x86_64-unknown-linux-gnu, I guess > ther

Re: Re: [PATCH V6] VECT: Add SELECT_VL support

Thanks a lot Richi. Even though last time Richard asked me no need to wait for 2nd ACK, I am still want to wait for Richard final approval since I am not sure this patch is ok for him. Thanks. juzhe.zh...@rivai.ai From: Richard Biener Date: 2023-06-09 19:02 To: Ju-Zhe Zhong CC: gcc-patches;

Re: [PATCH] Add COMPLEX_VECTOR_INT modes

On Fri, Jun 9, 2023 at 11:45 AM Andrew Stubbs wrote: > > On 09/06/2023 10:02, Richard Sandiford wrote: > > Andrew Stubbs writes: > >> On 07/06/2023 20:42, Richard Sandiford wrote: > >>> I don't know if this helps (probably not), but we have a similar > >>> situation on AArch64: a 64-bit mode like

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

On Fri, 9 Jun 2023, Richard Biener wrote: > On Fri, 9 Jun 2023, Richard Biener wrote: > > > The following makes sure that using TYPE_PRECISION on VECTOR_TYPE > > ICEs when tree checking is enabled. This should avoid wrong-code > > in cases like PR110182 and instead ICE. > > > > Bootstrap and re

Re: [PATCH] testsuite: fix the condition bug in tsvc s176

On Fri, Jun 9, 2023 at 11:58 AM Lehua Ding wrote: > > > It's odd that the checksum doesn't depend on the number of iterations done > > ... > > This is because the difference between the calculated result (32063.902344) > and > the expected result (32000.00) is small. The current check is tha

Re: [PATCH] Add COMPLEX_VECTOR_INT modes

Richard Biener writes: > On Fri, Jun 9, 2023 at 11:45 AM Andrew Stubbs wrote: >> >> On 09/06/2023 10:02, Richard Sandiford wrote: >> > Andrew Stubbs writes: >> >> On 07/06/2023 20:42, Richard Sandiford wrote: >> >>> I don't know if this helps (probably not), but we have a similar >> >>> situatio

[committed] libstdc++: Optimize std::to_array for trivial types [PR110167]

Tested powerpc64le-linux. Pushed to trunk. This makes sense to backport after some soak time on trunk. -- >8 -- As reported in PR libstdc++/110167, std::to_array compiles extremely slowly for very large arrays. It needs to instantiate a very large specialization of std::index_sequence and then c

[committed] libstdc++: Fix P2510R3 "Formatting pointers" [PR110149]

Tested powerpc64le-linux. Pushed to trunk. I'll backport it to gcc-13 later. -- >8 -- I had intended to support the P2510R3 proposal unconditionally in C++20 mode, but I left it half implemented. The parse function supported the new extensions, but the format function didn't. This adds the miss

[committed] libstdc++: Bump library version to libstdc++.so.6.0.33

Tested x86_64-linux, powerpc64le-linux, sparcv9-solaris. Pushed to trunk. There's no new GLIBCXX_3.4.33 symbol version yet, because we have nothing to put in it. The bump is because of the new CXXABI_1.3.15 version. -- >8 -- The addition of __cxa_call_terminate@@CXXABI_1.3.15 on trunk means we n

Re: [PATCH RFC] c++: use __cxa_call_terminate for MUST_NOT_THROW [PR97720]

On Fri, 9 Jun 2023 at 10:09, Jakub Jelinek wrote: > On Fri, Jun 09, 2023 at 11:02:48AM +0200, Richard Biener via Gcc-patches > wrote: > > > Currently both gcc-13 and trunk are at the same library version, > > > libstdc++.so.6.0.32 > > > > > > But with this addition to trunk we need to bump that .

[committed] libstdc++: Add preprocessor checks to [PR100285]

Tested x86_64-linux. Pushed to trunk. --> 8-- We can't define endpoints and resolvers without the relevant OS support. If IPPROTO_TCP and IPPROTO_UDP are both udnefined then we won't need basic_endpoint and basic_resovler anyway, so make them depend on those macros. libstdc++-v3/ChangeLog:

[committed] libstdc++: Remove duplicate definition of _Float128 std::from_chars [PR110077]

Tested powerpc64le-linux, sparc-solaris. Pushed to trunk. -- >8 -- When long double uses IEEE binary128 representation we define the _Float128 overload of std::from_chars inline in . My changes in r14-1431-g7037e7b6e4ac41 cause it to also be defined non-inline in the library, leading to an abi-ch

Re: [PATCH] fix frange_nextafter odr violation

On Jun 9, 2023, Richard Biener wrote: > On Thu, Jun 8, 2023 at 4:38 PM Alexandre Oliva via Gcc-patches > wrote: >> C++ requires inline functions to be declared inline and defined in >> every translation unit that uses them. frange_nextafter is used in >> gimple-range-op.cc but it's only defin

Ping: [PATCH] libatomic: x86_64: Always try ifunc

Ping (in hopes that someone can review before the weekend). On Sat, 2023-06-03 at 19:25 +0800, Xi Ruoyao wrote: > We used to skip ifunc check when CX16 is available.  But now we use > CX16+AVX+Intel/AMD for the "perfect" 16b load implementation, so CX16 > alone is not a sufficient reason not to us

Re: [PATCH] Make sure SCALAR_INT_MODE_P before invoke try_const_anchors

Hi, Richard Biener writes: > On Fri, 9 Jun 2023, Jiufu Guo wrote: > >> >> Hi, >> >> Richard Biener writes: >> >> > On Fri, 9 Jun 2023, Richard Sandiford wrote: >> > >> >> guojiufu writes: >> >> > Hi, >> >> > >> >> > On 2023-06-09 16:00, Richard Biener wrote: >> >> >> On Fri, 9 Jun 2023, J

Re: Ping: [PATCH] libatomic: x86_64: Always try ifunc

On Fri, Jun 09, 2023 at 08:37:20PM +0800, Xi Ruoyao wrote: > Ping (in hopes that someone can review before the weekend). > > On Sat, 2023-06-03 at 19:25 +0800, Xi Ruoyao wrote: > > We used to skip ifunc check when CX16 is available.  But now we use > > CX16+AVX+Intel/AMD for the "perfect" 16b load

Re: [PATCH] fix frange_nextafter odr violation

On Fri, Jun 9, 2023 at 2:26 PM Alexandre Oliva wrote: > > On Jun 9, 2023, Richard Biener wrote: > > > On Thu, Jun 8, 2023 at 4:38 PM Alexandre Oliva via Gcc-patches > > wrote: > > >> C++ requires inline functions to be declared inline and defined in > >> every translation unit that uses them.

Re: [PATCH] Make sure SCALAR_INT_MODE_P before invoke try_const_anchors

On Fri, 9 Jun 2023, Jiufu Guo wrote: > > Hi, > > Richard Biener writes: > > > On Fri, 9 Jun 2023, Jiufu Guo wrote: > > > >> > >> Hi, > >> > >> Richard Biener writes: > >> > >> > On Fri, 9 Jun 2023, Richard Sandiford wrote: > >> > > >> >> guojiufu writes: > >> >> > Hi, > >> >> > > >> >> >

Re: [PATCH 2/2] ipa-cp: Feed results of IPA-CP into value numbering

Hi, thanks for looking at this. On Fri, Jun 02 2023, Richard Biener wrote: > On Mon, 29 May 2023, Martin Jambor wrote: > [...] >> diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc >> index 27c84e78fcf..33215b5fc82 100644 >> --- a/gcc/tree-ssa-sccvn.cc >> +++ b/gcc/tree-ssa-sccvn.cc >>

Re: [PATCH] testsuite: fix the condition bug in tsvc s176

On 6/9/23 05:56, Richard Biener via Gcc-patches wrote: On Fri, Jun 9, 2023 at 11:58 AM Lehua Ding wrote: It's odd that the checksum doesn't depend on the number of iterations done ... This is because the difference between the calculated result (32063.902344) and the expected result (320

Re: [PATCH V2] Optimize '(X - N * M) / N' to 'X / N - M' if valid

Hi, Richard Biener writes: > On Wed, 7 Jun 2023, Jiufu Guo wrote: > >> Hi, >> >> This patch tries to optimize "(X - N * M) / N" to "X / N - M". >> For C code, "/" towards zero (trunc_div), and "X - N * M" maybe >> wrap/overflow/underflow. So, it is valid that "X - N * M" does >> not cross zer

Re: [PATCH] testsuite: fix the condition bug in tsvc s176

> I stitched together appropriate ChangeLog entries and pushed this to the  > trunk (I don't think Lehua has write access). Thank you! Best, Lehua

[PATCH] RISC-V: Fix V_WHOLE && V_FRACT iterator requirement

From: Juzhe-Zhong This patch fixes the requirement of V_WHOLE and V_FRACT. E.g. VNx8QI in V_WHOLE has no requirement which is incorrect. Actually, VNx8QI should be whole(full) mode when TARGET_MIN_VLEN < 128 since when TARGET_MIN_VLEN == 128, VNx8QI is e8mf2 which is fractional vec

Re: [PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

On 6/9/23 04:41, juzhe.zh...@rivai.ai wrote: From: Juzhe-Zhong This patch is to rework Phase 5 && Phase 6 of VSETVL PASS since Phase 5 && Phase 6 are quite messy and cause some bugs discovered by my downstream auto-vectorization test-generator. Before this patch. Phase 5 is cleanup_insns

Re: [PATCH] RISC-V: Fix V_WHOLE && V_FRACT iterator requirement

On 6/9/23 16:32, juzhe.zh...@rivai.ai wrote: > From: Juzhe-Zhong > > This patch fixes the requirement of V_WHOLE and V_FRACT. > E.g. VNx8QI in V_WHOLE has no requirement which is incorrect. > Actually, VNx8QI should be whole(full) mode when TARGET_MIN_VLEN < 128 > since when TARGET_MIN_

Re: Re: [PATCH] RISC-V: Fix V_WHOLE && V_FRACT iterator requirement

Ok. If you have done this plz go ahead. I think it shouldn't be with vec_set patch. Instead, it obviously should be the separate patch. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-06-09 22:37 To: juzhe.zhong; gcc-patches CC: rdapp.gcc; kito.cheng; palmer; jeffreyalaw Subject: Re: [PATCH]

Re: [PATCH V6] VECT: Add SELECT_VL support

On 6/9/23 05:32, juzhe.zh...@rivai.ai wrote: Thanks a lot Richi. Even though last time Richard asked me no need to wait for 2nd ACK, I am still want to wait for Richard final approval since I am not sure this patch is ok for him. If Richard had asked you to wait for Richi and you've done upd

Re: [PATCH] RISC-V: Fix V_WHOLE && V_FRACT iterator requirement

> I think it shouldn't be with vec_set patch. > Instead, it obviously should be the separate patch. Yes, I didn't mean in the actual same patch. Regards Robin

Re: Re: [PATCH V6] VECT: Add SELECT_VL support

Ok. Thanks Jeff. juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-06-09 22:42 To: juzhe.zh...@rivai.ai; rguenther CC: gcc-patches; richard.sandiford Subject: Re: [PATCH V6] VECT: Add SELECT_VL support On 6/9/23 05:32, juzhe.zh...@rivai.ai wrote: > Thanks a lot Richi. > > Even though last ti

Re: [PATCH] RISC-V: Fix V_WHOLE && V_FRACT iterator requirement

On 6/9/23 08:37, Robin Dapp wrote: On 6/9/23 16:32, juzhe.zh...@rivai.ai wrote: From: Juzhe-Zhong This patch fixes the requirement of V_WHOLE and V_FRACT. E.g. VNx8QI in V_WHOLE has no requirement which is incorrect. Actually, VNx8QI should be whole(full) mode when TARGET_MIN_VLEN < 1

Re: Re: [PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

Thanks Jeff. Actually, RTL_SSA framework is a very usefull tool very similar the framwork of SDnode of LLVM. which is the framework I am familar with. I just realize that the 2nd build of RTL_SSA causes bugs that's why I change it into data-flow. Address all comments will send V3 soon. Thanks.

Re: Re: [PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

>> I'd probably adjust the name as well. There's an important exception to >> returning the first vsetvl -- you stop the search if you encounter a >> user RVV instruction. Could you give me a function name of this? like: get_first_vsetvl_prior_all_rvv_insns is it ok? But I think the name is too

Re: [PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS

On 6/9/23 08:58, 钟居哲 wrote: I'd probably adjust the name as well. There's an important exception to returning the first vsetvl -- you stop the search if you encounter a user RVV instruction. Could you give me a function name of this? like: get_first_vsetvl_prior_all_rvv_insns is it ok? But

Re: [PATCH] simplify-rtx: Implement constant folding of SS_TRUNCATE, US_TRUNCATE

On 6/8/23 08:56, Kyrylo Tkachov via Gcc-patches wrote: Hi all, This patch implements RTL constant-folding for the SS_TRUNCATE and US_TRUNCATE codes. The semantics are a clamping operation on the argument with the min and max of the narrow mode, followed by a truncation. The signedness of th

[PATCH] c++: diagnostic ICE b/c of empty TPARMS_PRIMARY_TEMPLATE [PR109655]

When defining a previously declared class template, we neglect to set TPARMS_PRIMARY_TEMPLATE for the in-scope template parameters, which the class members go on to inherit, and so the members' DECL_TEMPLATE_PARMS will have empty TPARMS_PRIMARY_TEMPLATE at those levels as well. This causes us to c

[pushed] c++: init-list of uncopyable type [PR110102]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The maybe_init_list_as_range optimization is a form of copy elision, but we can only elide well-formed copies. PR c++/110102 gcc/cp/ChangeLog: * call.cc (maybe_init_list_as_array): Check that the element type is co

[pushed] c++: diagnose auto in template arg

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- We were failing to diagnose this Concepts TS feature that didn't make it into C++20 because the 'auto' was getting converted to a template parameter before we checked for it. So also check in cp_parser_simple_type_specifier. The code in cp

[pushed] c++: fix 32-bit spaceship failures [PR110185]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Various spaceship tests failed after r14-1624. This turned out to be because the comparison category classes return in memory on 32-bit targets, and the synthesized operator<=> looks something like if (auto v = a.x <=> b.x, v == 0); else r

Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)

Hi! The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes about 10 minutes to run for cris-elf in the "gdb simulator" here on my arguably way-past-retirement machine (and it looks like it gained a minute with LRA). I've seen it timing out every now and then on busy days with load > `nproc`.

[COMMITTED] Relocate range_cast to header, and add a generic version.

THis patch moves range_cast into the header file and makes it inlinable.  I also added a trap so that if you try to cast into an unsupported type, it traps.  It can't return a value of the correct type, so the caller needs to be doing something else... Such as using the new variant of range_c

[COMMITTED] PR ipa/109886 - Also check type being cast to

before casting into an irange, make sure the type being cast into is also supported by irange. Bootstrapped on x86_64-pc-linux-gnu with no regressions.  Pushed. Andrew From 6314d76cf87df92a0f7d0fdd48240283e667998a Mon Sep 17 00:00:00 2001 From: Andrew MacLeod Date: Fri, 9 Jun 2023 10:17:59 -04

Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)

On Jun 9, 2023, at 9:20 AM, Hans-Peter Nilsson via Gcc-patches wrote: > > The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes > about 10 minutes to run for cris-elf in the "gdb simulator" I'd let the libstdc++ people comment on specific things. I'll comment on general things. We could

[PATCH] MATCH: Fix zero_one_valued_p not to match signed 1 bit integers

So for the attached testcase, we assumed that zero_one_valued_p would be the value [0,1] but currently zero_one_valued_p matches also signed 1 bit integers. This changes that not to match that and fixes the 2 new testcases at all optimization levels. OK for GCC 13? Bootstrapped and tested on x86_6

Re: [PATCH V6] VECT: Add SELECT_VL support

"juzhe.zh...@rivai.ai" writes: > Thanks, Richi. > > Should I wait for Richard ACK gain ? > Since the last email of this patch, he just asked me to adjust comment no > codes change. > I am not sure whether he is ok. Yeah, OK from my POV too, thanks. Richard

Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)

> From: Mike Stump > Date: Fri, 9 Jun 2023 10:18:45 -0700 > On Jun 9, 2023, at 9:20 AM, Hans-Peter Nilsson via Gcc-patches > wrote: > > > > The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes > > about 10 minutes to run for cris-elf in the "gdb simulator" > > I'd let the libstdc++ peop

Re: [PATCH v3 4/6] libstdc++: use new built-in trait __is_function for std::is_function

On Sun, 2 Apr 2023, Ken Matsui via Gcc-patches wrote: > This patch gets std::is_function to dispatch to new built-in trait > __is_function. For std::is_function and other predicate-like type traits, I think we also want to make the corresponding variable template is_function_v directly use the bu

Re: [PATCH] simplify-rtx: Implement constant folding of SS_TRUNCATE, US_TRUNCATE

Kyrylo Tkachov via Gcc-patches writes: > Hi all, > > This patch implements RTL constant-folding for the SS_TRUNCATE and > US_TRUNCATE codes. > The semantics are a clamping operation on the argument with the min and max > of the narrow mode, > followed by a truncation. The signedness of the clamp

[PATCH 1/2] analyzer: Fix allocation size false positive on conjured svalue [PR109577]

Currently, the analyzer tries to prove that the allocation size is a multiple of the pointee's type size. This patch reverses the behavior to try to prove that the expression is not a multiple of the pointee's type size. With this change, each unhandled case should be gracefully considered as cor

[PATCH 2/2] testsuite: Add more allocation size tests for conjured svalues [PR110014]

This patch adds the reproducers reported in PR 110014 as test cases. The false positives in those cases are already fixed with PR 109577. 2023-06-09 Tim Lange PR analyzer/110014 gcc/testsuite/ChangeLog: * gcc.dg/analyzer/pr110014.c: New tests. --- gcc/testsuite/gcc.dg/analy

Re: [PATCH 1/2] analyzer: Fix allocation size false positive on conjured svalue [PR109577]

On Fri, 2023-06-09 at 20:28 +0200, Tim Lange wrote: [...snip...] Thanks for the patch. > diff --git a/gcc/analyzer/constraint-manager.cc > b/gcc/analyzer/constraint-manager.cc > index 2c9c435527e..24cd8960098 100644 > --- a/gcc/analyzer/constraint-manager.cc > +++ b/gcc/analyzer/constraint-man

Re: [PATCH 2/2] testsuite: Add more allocation size tests for conjured svalues [PR110014]

On Fri, 2023-06-09 at 20:28 +0200, Tim Lange wrote: > This patch adds the reproducers reported in PR 110014 as test cases. > The > false positives in those cases are already fixed with PR 109577. > > 2023-06-09  Tim Lange  > > PR analyzer/110014 > > gcc/testsuite/ChangeLog: > >    

Re: [PATCH V2] Optimize '(X - N * M) / N' to 'X / N - M' if valid

Hi! On Wed, Jun 07, 2023 at 04:21:11PM +0800, Jiufu Guo wrote: > This patch tries to optimize "(X - N * M) / N" to "X / N - M". > For C code, "/" towards zero (trunc_div), and "X - N * M" maybe > wrap/overflow/underflow. So, it is valid that "X - N * M" does > not cross zero and does not wrap/over

Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)

On Fri, 9 Jun 2023 at 17:20, Hans-Peter Nilsson wrote: > Hi! > > The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes > about 10 minutes to run for cris-elf in the "gdb simulator" > here on my arguably way-past-retirement machine (and it > looks like it gained a minute with LRA). I've seen

Re: [PATCH] MATCH: Fix zero_one_valued_p not to match signed 1 bit integers

On 6/9/23 11:27, Andrew Pinski via Gcc-patches wrote: So for the attached testcase, we assumed that zero_one_valued_p would be the value [0,1] but currently zero_one_valued_p matches also signed 1 bit integers. This changes that not to match that and fixes the 2 new testcases at all optimizati

  1   2   >