[PATCH] RISC-V: Remove unnecessary md pattern for TARGET_XTHEADCONDMOV

There are 2 small changes in this patch, but they do not affect the result. 1. Remove unnecessary md pattern for TARGET_XTHEADCONDMOV in thead.md. The operands[4] in "if_then_else" are always comparison operations, so the generated rtl does not match the pattern that is expected to be deleted.

Re: [PATCH] RISC-V: Fix warning in predicated.md

Ok 於 2023年6月2日 週五 11:05 寫道： > From: Juzhe-Zhong > > Notice there is warning in predicates.md: > ../../../riscv-gcc/gcc/config/riscv/predicates.md: In function ‘bool > arith_operand_or_mode_mask(rtx, machine_mode)’: > ../../../riscv-gcc/gcc/config/riscv/predicates.md:33:14: warning: >

Re: [PATCH v5] tree-ssa-sink: Improve code sinking pass

On 01/06/23 2:06 pm, Bernhard Reutner-Fischer wrote: > On 1 June 2023 09:20:08 CEST, Ajit Agarwal wrote: >> Hello All: >> >> This patch improves code sinking pass to sink statements before call to >> reduce >> register pressure. >> Review comments are incorporated. > > Hi Ajit! > > I had

Re: ping^^: [PATCH] rs6000: Enable const_anchor for 'addi'

Hi David, Thanks! David Edelsohn writes: > This Message Is From an External Sender > This message came from outside your organization. > > On Tue, May 30, 2023 at 11:00 PM Jiufu Guo wrote: > > Gentle ping... > > Jiufu Guo via Gcc-patches writes: > > > Gentle ping... > > > > Jiufu

Re: [RFC] light expander sra for parameters and returns

Hi, Richard Biener writes: > On Mon, 29 May 2023, Jiufu Guo wrote: > >> Hi, >> >> Previously, I was investigating some struct parameters and returns related >> PRs 69143/65421/108073. >> >> Investigating the issues case by case, and drafting patches for each of >> them one by one. This

Re: [RFC] light expander sra for parameters and returns

Hi, Martin Jambor writes: > Hi, > > On Tue, May 30 2023, Richard Biener wrote: >> On Mon, 29 May 2023, Jiufu Guo wrote: >> >>> Hi, >>> >>> Previously, I was investigating some struct parameters and returns related >>> PRs 69143/65421/108073. >>> >>> Investigating the issues case by case,

Re: [PATCH] rs6000: Fix __builtin_vec_xst_trunc definition

on 2023/6/2 04:01, Carl Love wrote: > On Wed, 2023-05-31 at 12:59 -0500, Peter Bergner wrote: >> On 5/22/23 4:04 AM, Kewen.Lin wrote: >>> on 2023/5/11 02:06, Carl Love via Gcc-patches wrote: @@ -3161,12 +3161,15 @@ void __builtin_altivec_tr_stxvrbx (vsq, signed long, signed char

[PATCH] RISC-V: Fix warning in predicated.md

From: Juzhe-Zhong Notice there is warning in predicates.md: ../../../riscv-gcc/gcc/config/riscv/predicates.md: In function ???bool arith_operand_or_mode_mask(rtx, machine_mode)???: ../../../riscv-gcc/gcc/config/riscv/predicates.md:33:14: warning: comparison between signed and unsigned integer

Re: [PATCH] rs6000: Fix arguments for __builtin_altivec_tr_stxvrwx, __builtin_altivec_tr_stxvrhx

Hi Carl, on 2023/6/2 04:01, Carl Love wrote: > Kewen, Segher, Peter: > > The following patch is a redo of the previous "rs6000: Fix > __builtin_vec_xst_trunc definition" patch. > > This patch fixes the argument in the two builtin definitions > __builtin_altivec_tr_stxvrwx and

[PATCH RFA] varasm: check float size

Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- In PR95226, the testcase was failing because we tried to output_constant a NOP_EXPR to float from a double REAL_CST, and so we output a double where the caller wanted a float. That doesn't happen anymore, but with the output_constant hunk we

Followup on PR/109279: large constants on RISCV

Hi Jeff, I finally got around to collecting various observations on PR/109279 - more importantly the state of large constants in RV backend, apologies in advance for the long email. It seems the various commits in area have improved the original test case of 0x1010101_01010101   Before

[COMMITTED] MAINTAINERS: Add myself as MIPS port maintainer

ChangeLog: * MAINTAINERS (CPU Port Maintainers): Add myself as MIPS port maintainer. (Write After Approval): Remove myself. --- MAINTAINERS | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4a7c963914b..c8b787b6e1e

[PATCH V2] RISC-V: Add _mu C++ overloaded intrinsics for load && viota && vid

From: Juzhe-Zhong Base on these: https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/232 https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/233 Add _mu C++ overloaded intrinsics for load && viota && vid. Co-authored-by: KuanLin Chen gcc/ChangeLog: *

[PATCH] RISC-V: Add _mu C++ overloaded intrinsics for load && viota && vid

From: Juzhe-Zhong Base on these: https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/232 https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/233 Add _mu C++ overloaded intrinsics for load && viota && vid. Co-authored-by: KuanLin Chen gcc/ChangeLog: *

Re: Re: [PATCH] RISC-V: Add _mu C++ overloaded intrinsics for load && viota && vid

Oh. Yes. Thanks for catching this! Will send V2 soon. juzhe.zh...@rivai.ai From: KuanLin Chen Date: 2023-06-02 09:26 To: gcc-patches; juzhe.zhong CC: kito.cheng; palmer; rdapp.gcc; jeffreyalaw Subject: Re: [PATCH] RISC-V: Add _mu C++ overloaded intrinsics for load && viota && vid Hi Juzhe,

[PATCH RFA] c++: make initializer_list array static again [PR110070]

I ended up deciding not to apply the DECL_NOT_OBSERVABLE patch that you approved in stage 3 because I didn't feel like it was fully baked; I'm happy with this version now, which seems like a more broadly useful flag. Tested x86_64-pc-linux-gnu. OK for trunk? -- 8< -- After the

Re: [PATCH] RISC-V: Add _mu C++ overloaded intrinsics for load && viota && vid

Hi Juzhe, I think fault_load_def::get_name should remove "instance.pred == PRED_TYPE_mu", right? 於 2023年6月2日 週五 上午7:05寫道： > > From: Juzhe-Zhong > > Base on these: > https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/232 > https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/233 > >

RE: [PATCH] RISC-V: Add test for vfloat16*_t (non tuple) types

Committed, thanks Kito. Pan From: Kito Cheng Sent: Thursday, June 1, 2023 11:36 PM To: Li, Pan2 Cc: Wang, Yanzhang ; gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com Subject: Re: [PATCH] RISC-V: Add test for vfloat16*_t (non tuple) types Lgtm Li, Pan2 via Gcc-patches

RE: [PATCH] RISC-V: Add __RISCV_ prefix to VXRM and FRM enum

Committed, thanks Jeff. Pan -Original Message- From: Gcc-patches On Behalf Of Jeff Law via Gcc-patches Sent: Friday, June 2, 2023 7:49 AM To: juzhe.zh...@rivai.ai; gcc-patches@gcc.gnu.org Cc: kito.ch...@sifive.com; pal...@rivosinc.com; rdapp@gmail.com Subject: Re: [PATCH] RISC-V:

RE: [PATCH] RISC-V: Add vwadd.wv/vwsub.wv auto-vectorization lowering optimization

Committed, thanks Jeff. Pan -Original Message- From: Gcc-patches On Behalf Of Jeff Law via Gcc-patches Sent: Friday, June 2, 2023 2:52 AM To: juzhe.zh...@rivai.ai; gcc-patches@gcc.gnu.org Cc: kito.ch...@gmail.com; kito.ch...@sifive.com; pal...@dabbelt.com; pal...@rivosinc.com;

RE: [PATCH V2] RISC-V: Support RVV permutation auto-vectorization

Committed, thanks Jeff. Pan -Original Message- From: Gcc-patches On Behalf Of Jeff Law via Gcc-patches Sent: Friday, June 2, 2023 2:49 AM To: juzhe.zh...@rivai.ai; gcc-patches@gcc.gnu.org Cc: kito.ch...@gmail.com; kito.ch...@sifive.com; pal...@dabbelt.com; pal...@rivosinc.com;

[PATCH] [vect]Use intermiediate integer type for float_expr/fix_trunc_expr when direct optab is not existed.

We have already use intermidate type in case WIDEN, but not for NONE, this patch extended that. I didn't do that in pattern recog since we need to know whether the stmt belongs to any slp_node to decide the vectype, the related optabs are checked according to vectype_in and vectype_out. For

[PATCH] i386: Add missing vector truncate patterns [PR92658].

Add missing insn patterns for v2si -> v2hi/v2qi and v2hi-> v2qi vector truncate. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk? gcc/ChangeLog: PR target/92658 * config/i386/mmx.md (truncv2hiv2qi2): New define_insn. (truncv2si2): Ditto.

Re: [PATCH] RISC-V: Add __RISCV_ prefix to VXRM and FRM enum

On 6/1/23 17:19, juzhe.zh...@rivai.ai wrote: From: Juzhe-Zhong According to doc: https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222/files https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/226 Add __RISCV_ prefix to VXRM and FRM enum. gcc/ChangeLog: *

[PATCH] RISC-V: Add __RISCV_ prefix to VXRM and FRM enum

From: Juzhe-Zhong According to doc: https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222/files https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/226 Add __RISCV_ prefix to VXRM and FRM enum. gcc/ChangeLog: * config/riscv/riscv-vector-builtins.cc (DEF_RVV_VXRM_ENUM): Add

rs6000: Fix expected counts powerpc/p9-vec-length-full

GCC maintainers: The following patch updates the expected instruction counts in four tests. The counts in all of the tests changed with commit f574e2dfae79055f16d0c63cc12df24815d8ead6. The updated counts have been verified on both Power 9 and Power 10. Please let me know if this patch is

[PATCH] RISC-V: Add _mu C++ overloaded intrinsics for load && viota && vid

From: Juzhe-Zhong Base on these: https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/232 https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/233 Add _mu C++ overloaded intrinsics for load && viota && vid. gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc: Add _mu

Re: [PATCH] Move std::search into algobase.h

On Thu, 1 Jun 2023, 21:37 François Dumont via Libstdc++, < libstd...@gcc.gnu.org> wrote: > It's of course not as easy as I thought. > > I would never have detected this problem on my system because I'm > missing omp.h. > > I've implemented and added a: > > // { dg-require-effective-target omp } >

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

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 TEMPLATE_TEMPLATE_PARM instead of just

Re: [PATCH] Fortran: force error on bad KIND specifier [PR88552]

Hi Mikael, Am 01.06.23 um 22:33 schrieb Mikael Morin: Hello, Le 01/06/2023 à 21:05, Harald Anlauf via Fortran a écrit : Dear all, we sometimes silently accept wrong declarations with unbalanced parentheses, as the PR and testcases therein show. It appears that the fix is obvious: use the

Re: [PATCH] Fix PR 110042: ifcvt regression due to paradoxical subregs

On Thu, Jun 1, 2023 at 7:36 AM Jeff Law wrote: > > > > On 5/31/23 15:22, Andrew Pinski wrote: > > On Wed, May 31, 2023 at 12:29 AM Richard Biener via Gcc-patches > > wrote: > >> > >> On Wed, May 31, 2023 at 6:34 AM Andrew Pinski via Gcc-patches > >> wrote: > >>> > >>> After

Re: [PATCH] Move std::search into algobase.h

It's of course not as easy as I thought. I would never have detected this problem on my system because I'm missing omp.h. I've implemented and added a: // { dg-require-effective-target omp } so that now those tests are UNRESOLVED rather than PASS. Now I've install OMP and try to rebuild

Re: [PATCH] Fortran: force error on bad KIND specifier [PR88552]

Hello, Le 01/06/2023 à 21:05, Harald Anlauf via Fortran a écrit : Dear all, we sometimes silently accept wrong declarations with unbalanced parentheses, as the PR and testcases therein show. It appears that the fix is obvious: use the existing error paths in gfc_match_kind_spec and error

Re: [PATCH 2/2] libstdc++: Replace all manual FTM definitions and use

On Sat, 29 Apr 2023 at 11:24, Arsen Arsenović via Libstdc++ < libstd...@gcc.gnu.org> wrote: > libstdc++-v3/ChangeLog: > > * libsupc++/typeinfo: Switch to bits/version.h for > __cpp_lib_constexpr_typeinfo. > > Does this change have an impact on compilation speed? With this change

[RFC] range-op restructuring

With the addition of floating point ranges, we did a lot of additional class abstraction, then added a bunch more routines for floating point. We didn't know how it would look in the end, so we just marched forward and got it working. Now that has settled down a bit, and before we go and add

Re: [PATCH 1/2] libstdc++: Implement more maintainable header

On Sat, 29 Apr 2023 at 11:25, Arsen Arsenović via Libstdc++ < libstd...@gcc.gnu.org> wrote: > This commit replaces the ad-hoc logic in with an AutoGen > database that (mostly) declaratively generates a version.h bit which > combines all of the FTM logic across all headers together. > > This

[PATCH] rs6000: Fix arguments for __builtin_altivec_tr_stxvrwx, __builtin_altivec_tr_stxvrhx

Kewen, Segher, Peter: The following patch is a redo of the previous "rs6000: Fix __builtin_vec_xst_trunc definition" patch. This patch fixes the argument in the two builtin definitions __builtin_altivec_tr_stxvrwx and __builtin_altivec_tr_stxvrhx. It also adds with a testcase to validate the

Re: [PATCH] rs6000: Fix __builtin_vec_xst_trunc definition

On Wed, 2023-05-31 at 12:59 -0500, Peter Bergner wrote: > On 5/22/23 4:04 AM, Kewen.Lin wrote: > > on 2023/5/11 02:06, Carl Love via Gcc-patches wrote: > > > @@ -3161,12 +3161,15 @@ > > >void __builtin_altivec_tr_stxvrbx (vsq, signed long, signed > > > char *); > > > TR_STXVRBX

[Committed] testsuite: print any leaking torture options for debugging

This was helpful when debugging the recent multilib testsuite failure. gcc/testsuite: * lib/torture-options.exp: print the value of non-empty options: torture_without_loops, torture_with_loops, LTO_TORTURE_OPTIONS. Signed-off-by: Vineet Gupta ---

[Committed] testsuite: Unbork multilib setups using -march flags (RISC-V)

RISC-V multilib testing is currently busted with follow splat all over: |Schedule of variations: |riscv-sim/-march=rv64imafdc/-mabi=lp64d/-mcmodel=medlow |riscv-sim/-march=rv32imafdc/-mabi=ilp32d/-mcmodel=medlow |riscv-sim/-march=rv32imac/-mabi=ilp32/-mcmodel=medlow |

Re: [PATCH 2/3] RISC-V: Add missing torture-init and torture-finish for rvv.exp

On 6/1/23 07:54, Jeff Law wrote: On 5/31/23 10:25, Vineet Gupta wrote: From: Kito Cheng This is in line with recent test harness expectations and is a preventive change as it doesn't actually fix any errors. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/rvv.exp: Add torture-init and

[PATCH] Fortran: force error on bad KIND specifier [PR88552]

Dear all, we sometimes silently accept wrong declarations with unbalanced parentheses, as the PR and testcases therein show. It appears that the fix is obvious: use the existing error paths in gfc_match_kind_spec and error return from gfc_match_decl_type_spec. I'm still posting it here in case I

Re: [PATCH] RISC-V: Add vwadd.wv/vwsub.wv auto-vectorization lowering optimization

On 5/31/23 21:48, juzhe.zh...@rivai.ai wrote: From: Juzhe-Zhong 1. This patch optimize the codegen of the following auto-vectorization codes: void foo (int32_t * __restrict a, int64_t * __restrict b, int64_t * __restrict c, int n) { for (int i = 0; i < n; i++) c[i] =

Re: [PATCH V2] RISC-V: Support RVV permutation auto-vectorization

On 5/31/23 20:36, juzhe.zh...@rivai.ai wrote: From: Juzhe-Zhong This patch supports vector permutation for VLS only by vec_perm pattern. We will support TARGET_VECTORIZE_VEC_PERM_CONST to support VLA permutation in the future. Fixed following comments from Robin. Ok for trunk?

Re: [PATCH] doc: clarify semantics of vector bitwise shifts

On Wed, 31 May 2023, Richard Biener wrote: > On Tue, May 30, 2023 at 4:49 PM Alexander Monakov wrote: > > > > > > On Thu, 25 May 2023, Richard Biener wrote: > > > > > On Wed, May 24, 2023 at 8:36 PM Alexander Monakov > > > wrote: > > > > > > > > > > > > On Wed, 24 May 2023, Richard Biener

Re: [PATCH 04/14] c++: use _P() defines from tree.h

Hi David, Patrick, On Thu, 1 Jun 2023 18:33:46 +0200 Bernhard Reutner-Fischer wrote: > On Thu, 1 Jun 2023 11:24:06 -0400 > Patrick Palka wrote: > > > On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via > > Gcc-patches wrote: > > > > diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc >

Re: [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement

Le 01/06/2023 à 17:20, Paul Richard Thomas via Fortran a écrit : Hi All, This started out as the search for a fix to pr109948 and evolved to roll in 5 other prs. Basically parse_associate was far too clunky and, in anycase, existing functions in resolve.cc were well capable of doing the

Re: FW: [RFC] RISC-V: Support risc-v bfloat16 This patch support bfloat16 in riscv like x86_64 and arm.

On 6/1/23 10:56, Palmer Dabbelt wrote: On Thu, 01 Jun 2023 09:48:47 PDT (-0700), jeffreya...@gmail.com wrote: On 6/1/23 01:01, juzhe.zh...@rivai.ai wrote: I plan to implement BF16 vector in GCC but still waiting for ISA ratified since GCC policy doesn't allow un-ratified ISA. Right.  So

Re: FW: [RFC] RISC-V: Support risc-v bfloat16 This patch support bfloat16 in riscv like x86_64 and arm.

On Thu, 1 Jun 2023 at 18:49, Jeff Law via Gcc-patches wrote: > > > > On 6/1/23 01:01, juzhe.zh...@rivai.ai wrote: > > I plan to implement BF16 vector in GCC but still waiting for ISA > > ratified since GCC policy doesn't allow un-ratified ISA. > Right. So those specs need to move along further

Re: FW: [RFC] RISC-V: Support risc-v bfloat16 This patch support bfloat16 in riscv like x86_64 and arm.

On Thu, 01 Jun 2023 09:48:47 PDT (-0700), jeffreya...@gmail.com wrote: On 6/1/23 01:01, juzhe.zh...@rivai.ai wrote: I plan to implement BF16 vector in GCC but still waiting for ISA ratified since GCC policy doesn't allow un-ratified ISA. Right. So those specs need to move along further

Re: FW: [RFC] RISC-V: Support risc-v bfloat16 This patch support bfloat16 in riscv like x86_64 and arm.

On 6/1/23 01:01, juzhe.zh...@rivai.ai wrote: I plan to implement BF16 vector in GCC but still waiting for ISA ratified since GCC policy doesn't allow un-ratified ISA. Right. So those specs need to move along further before we can start integrating code. Currently, we are working on

Re: [PATCH 04/14] c++: use _P() defines from tree.h

On Thu, 1 Jun 2023 11:24:06 -0400 Patrick Palka wrote: > On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via > Gcc-patches wrote: > > diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc > > index 131b212ff73..19dfb3ed782 100644 > > --- a/gcc/cp/tree.cc > > +++ b/gcc/cp/tree.cc > > @@ -1173,7

[PATCH] gimple-range: implement widen plus range

Hi, This patch adds gimple-range information for the new IFN_VEC_WIDEN_PLUS* internal functions, identical to what VEC_WIDEN_PLUS did. Bootstrapped and regression tested on aarch64-unknown-linux-gnu. gcc/ChangeLog: * gimple-range-op.cc (gimple_range_op_handler::maybe_non_standard):

[PATCH] inline: improve internal function costs

Hi, This is a follow-up of the internal function patch to add widening and narrowing patterns. This patch improves the inliner cost estimation for internal functions. Bootstrapped and regression tested on aarch64-unknown-linux-gnu. gcc/ChangeLog: * ipa-fnsummary.cc

Re: [PATCH 2/3] Refactor widen_plus as internal_fn

Hi, This is the updated patch and cover letter. Patches for inline and gimple-op changes will follow soon. DEF_INTERNAL_WIDENING_OPTAB_FN and DEF_INTERNAL_NARROWING_OPTAB_FN are like DEF_INTERNAL_SIGNED_OPTAB_FN and DEF_INTERNAL_OPTAB_FN respectively. With the exception that they

[PATCH] libstdc++: Use AS_IF in configure.ac

Tested x86_64-linux. I'd appreciate a second set of eyeballs on this before I push it. -- >8 -- This ensures that anything that depends on AC_REQUIRE is hoisted out of the conditional block. The always-false test x"long_double_math_on_this_cpu" = x"yes" condition is not altered by this commit,

[committed] libstdc++: Fix PSTL test that fails in C++20

Tested x86_64-linux. Pushed to trunk, will backport too. Tom, this will require rebasing your PSTL rebase patch, but it should be trivial. -- >8 -- This test fails in C++20 and later due to a warning: warning: C++20 says that these are ambiguous, even though the second is reversed: note:

Re: [PATCH] c++: ahead of time variable template-id coercion [PR89442]

On Wed, May 3, 2023 at 9:50 AM Patrick Palka wrote: > > This patch makes us coerce the arguments of a variable template-id ahead > of time, as we do for other template-ids, which allows us to immediately > diagnose template parameter/argument kind mismatches and arity mismatches. > >

Re: [PATCH 2/3 v3] xtensa: Add 'adddi3' and 'subdi3' insn patterns

On 2023/06/01 23:20, Max Filippov wrote: > On Wed, May 31, 2023 at 11:01 PM Takayuki 'January June' Suwa > wrote: >> More optimized than the default RTL generation. >> >> gcc/ChangeLog: >> >> * config/xtensa/xtensa.md (adddi3, subdi3): >> New RTL generation patterns implemented

Re: [PATCH] RISC-V: Add test for vfloat16*_t (non tuple) types

Lgtm Li, Pan2 via Gcc-patches 於 2023年6月1日 週四，20:10寫道： > Thanks Juzhe for pointing out this. > > Pan > > -Original Message- > From: Li, Pan2 > Sent: Thursday, June 1, 2023 8:09 PM > To: gcc-patches@gcc.gnu.org > Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Li, Pan2 < >

Re: [RFC] light expander sra for parameters and returns

Hi, On Tue, May 30 2023, Richard Biener wrote: > On Mon, 29 May 2023, Jiufu Guo wrote: > >> Hi, >> >> Previously, I was investigating some struct parameters and returns related >> PRs 69143/65421/108073. >> >> Investigating the issues case by case, and drafting patches for each of >> them one

Re: [PATCH 04/14] c++: use _P() defines from tree.h

On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via Gcc-patches wrote: > > From: Bernhard Reutner-Fischer > > gcc/cp/ChangeLog: > > * call.cc (promoted_arithmetic_type_p): Use _P defines from tree.h. > (build_conditional_expr): Ditto. > (convert_like_internal):

[Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement

Hi All, This started out as the search for a fix to pr109948 and evolved to roll in 5 other prs. Basically parse_associate was far too clunky and, in anycase, existing functions in resolve.cc were well capable of doing the determination of the target expression rank. While I was checking the

[committed] libstdc++: Do not use std::expected::value() in monadic ops (LWG 3938)

Tested powerpc64le-linux. Pusshed to trunk. -- >8 -- The monadic operations in std::expected always check has_value() so we can avoid the execptional path in value() and the assertions in error() by accessing _M_val and _M_unex directly. This means that the monadic operations no longer require

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

Tested powerpc64le-linux. Pusshed to trunk. -- >8 -- My r14-1452-gfb409a15d9babc change to add optimization hints to std::vector causes regressions because it makes std::vector::size() and std::vector::capacity() too big to inline. That's the opposite of what I wanted, so revert the changes to

[committed] libstdc++: Document removal of implicit allocator rebinding extensions

Pushed to trunk. The first two changes will be backported too. -- >8 -- Traditionally libstdc++ allowed containers and strings to be instantiated with allocator's that have the wrong value type, implicitly rebinding the allocator to the container's value type. Since C++20 that has been

Re: [PATCH] doc: improve docs for -pedantic{,-errors}

On 5/31/23 21:31, Jason Merrill via Gcc-patches wrote: Tested by looking at the makeinfo output. OK for trunk? -- 8< -- Recent discussion of -Wimplicit led me to want to clarify this section of the documentation, and mark which diagnostics other than -Wpedantic are affected by

Re: [PATCH 2/3] RISC-V: Add missing torture-init and torture-finish for rvv.exp

On 5/31/23 10:25, Vineet Gupta wrote: From: Kito Cheng This is in line with recent test harness expectations and is a preventive change as it doesn't actually fix any errors. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/rvv.exp: Add torture-init and torture-finish.

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

On 5/31/23 10:25, Vineet Gupta wrote: Multilib testing on trunk is currently busted (and surprisingly this affects any/all targets but it seems nobody cares). We currently get the following splat: | ERROR: tcl error code NONE | ERROR: torture-init: torture_without_loops is not empty as

Re: [PATCH 3/3] testsuite: print any leaking torture options for debugging

On 5/31/23 10:25, Vineet Gupta wrote: This was helpful when debugging the recent multilib testsuite failure. gcc/testsuite: * lib/torture-options.exp: print the value of non-empty options: torture_without_loops, torture_with_loops, LTO_TORTURE_OPTIONS. OK jeff

[PATCH 2/2] c++: partial ordering and dep alias tmpl specs [PR90679]

During partial ordering, we want to look through dependent alias template specializations within template arguments and otherwise treat them as opaque in other contexts (see e.g. r7-7116-g0c942f3edab108 and r11-7011-g6e0a231a4aa240). To that end template_args_equal was given a partial_order flag

[PATCH 1/2] c++: refine dependent_alias_template_spec_p [PR90679]

For a complex alias template-id, dependent_alias_template_spec_p returns true if any template argument of the template-id is dependent. This predicate indicates that substitution into the template-id may behave differently with respect to SFINAE than substitution into the expanded alias, and so

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

On 6/1/23 01:24, Thomas Schwinge wrote: But probably more importantly, this problem seems to not be triggering on all multilib targets. For example, I just examined my tester's build logs and couldn't see this on the H8/300 or V850 ports. Which begs the question, why? ..., which may

Re: [PATCH] Fix PR 110042: ifcvt regression due to paradoxical subregs

On 5/31/23 15:22, Andrew Pinski wrote: On Wed, May 31, 2023 at 12:29 AM Richard Biener via Gcc-patches wrote: On Wed, May 31, 2023 at 6:34 AM Andrew Pinski via Gcc-patches wrote: After r14-1014-gc5df248509b489364c573e8, GCC started to emit directly a zero_extract for `(t1&0x8)!=0`. This

[COMMITTED] cse: Change return type of predicate functions from int to bool

Also change some function arguments to bool and remove one instance of always zero function argument. gcc/ChangeLog: * rtl.h (exp_equiv_p): Change return type from int to bool. * cse.cc (mention_regs): Change return type from int to bool and adjust function body accordingly.

Re: [PATCH 2/3 v3] xtensa: Add 'adddi3' and 'subdi3' insn patterns

On Wed, May 31, 2023 at 11:01 PM Takayuki 'January June' Suwa wrote: > More optimized than the default RTL generation. > > gcc/ChangeLog: > > * config/xtensa/xtensa.md (adddi3, subdi3): > New RTL generation patterns implemented according to the instruc- > tion idioms

Re: [PATCH 2/3 v3] xtensa: Add 'adddi3' and 'subdi3' insn patterns

On Wed, May 31, 2023 at 11:01 PM Takayuki 'January June' Suwa wrote: > More optimized than the default RTL generation. > > gcc/ChangeLog: > > * config/xtensa/xtensa.md (adddi3, subdi3): > New RTL generation patterns implemented according to the instruc- > tion idioms

Re: [PATCH] Move std::search into algobase.h

Sorry, I had fully tested the move from bits/stl_algo.h to bits/stl_algobase.h. But it appears that the script I used to run the tests after the other move has not done what I expected. I'll provide the patch shortly. Le jeu. 1 juin 2023 à 14:06, Jonathan Wakely a écrit : > > > On Thu, 1 Jun

RE: [PATCH] RISC-V: Add test for vfloat16*_t (non tuple) types

Thanks Juzhe for pointing out this. Pan -Original Message- From: Li, Pan2 Sent: Thursday, June 1, 2023 8:09 PM To: gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Li, Pan2 ; Wang, Yanzhang Subject: [PATCH] RISC-V: Add test for vfloat16*_t (non tuple) types

[PATCH] RISC-V: Add test for vfloat16*_t (non tuple) types

From: Pan Li This patch would like to add some test cases of vfloat16*_t (non tuple), no 'zvfh' or 'zvfhmin' will meet unknown type. Signed-off-by: Pan Li gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/abi-16.c: Add test cases. * gcc.target/riscv/rvv/base/user-7.c:

Re: [PATCH] Move std::search into algobase.h

On Thu, 1 Jun 2023 at 12:52, Rainer Orth wrote: > Jonathan Wakely via Gcc-patches writes: > > > On Wed, 31 May 2023 at 18:39, François Dumont via Libstdc++ < > > libstd...@gcc.gnu.org> wrote: > > > >> libstdc++: Reduce inclusion to > >> > >> > >> Move the std::search definition from

Re: [PATCH 2/3] RISC-V: Add missing torture-init and torture-finish for rvv.exp

Hi! On 2023-05-31T09:25:33-0700, Vineet Gupta wrote: > From: Kito Cheng > > This is in line with recent test harness expectations and is a > preventive change as it doesn't actually fix any errors. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/rvv/rvv.exp: Add torture-init and >

Re: [PATCH] Move std::search into algobase.h

Jonathan Wakely via Gcc-patches writes: > On Wed, 31 May 2023 at 18:39, François Dumont via Libstdc++ < > libstd...@gcc.gnu.org> wrote: > >> libstdc++: Reduce inclusion to >> >> >> Move the std::search definition from stl_algo.h to stl_algobase.h and use >> the later in . >> >> For consistency

Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

Hi! On 2023-06-01T09:24:20+0200, I wrote: > First, Vineet, great that you've now tracked this down! :-) Indeed > "early exit" vs. 'torture-finish' was exactly the issue that I suspected. > > It may not be what you originally intended, but I hope at least you've > learned some things about

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

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 trunk. > > > > -- >8 -- > > > > We use the from_chars_strtod function with

Re: [PATCH] doc: Fix description of x86 -m32 option [PR109954]

On Thu, Jun 01, 2023 at 11:37:37AM +0100, Jonathan Wakely via Gcc-patches wrote: > In https://gcc.gnu.org/PR109954 I suggested also adding: > > "N.B., using @option{-march} might be required to produce code suitable > for a specific CPU family, e.g., @option{-march=i486}." > > I realise that

[PATCH] doc: Fix description of x86 -m32 option [PR109954]

In https://gcc.gnu.org/PR109954 I suggested also adding: "N.B., using @option{-march} might be required to produce code suitable for a specific CPU family, e.g., @option{-march=i486}." I realise that that is true for all of -m32, -m64 and -mx32, and similar rules apply for other targets too. But

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

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 trunk. > > -- >8 -- > > We use the from_chars_strtod function with __strtof128 to read a > _Float128 value, but from_chars_strtod is not defined unless

Re: [PATCH] libstdc++: optimize EH phase 2

On Thu, 1 Jun 2023 at 04:13, Jason Merrill via Libstdc++ < libstd...@gcc.gnu.org> wrote: > Tested x86_64-pc-linux-gnu, OK for trunk? > OK, thanks. > > -- 8< -- > > In the ABI's two-phase EH model, first we walk the stack looking for a > handler, then we walk the stack running cleanups until we

Re: [r14-1452 Regression] FAIL: g++.dg/pr104547.C -std=gnu++17 scan-tree-dump-not vrp2 "_M_default_append" on Linux/x86_64

On Thu, 1 Jun 2023 at 10:06, Christophe Lyon wrote: > Hi! > > We have noticed the same problem on aarch64, if that's easier to reproduce. > I am already testing a fix.

Re: [RFC] RISC-V: Support risc-v bfloat16 This patch support bfloat16 in riscv like x86_64 and arm.

Hi, Ma Jin     1. There are few developments since May in GCC because the spec of Zfbf is constantly changing.     2. We (PLCT lab) will implement Zvfbfmin and Zvfbfwma after Zvfh has been merged in GCC.     3. I will send a patch to support

Re: [r14-1452 Regression] FAIL: g++.dg/pr104547.C -std=gnu++17 scan-tree-dump-not vrp2 "_M_default_append" on Linux/x86_64

Hi! We have noticed the same problem on aarch64, if that's easier to reproduce. Thanks, Christophe On Thu, 1 Jun 2023 at 06:20, haochen.jiang via Gcc-regression < gcc-regress...@gcc.gnu.org> wrote: > On Linux/x86_64, > > fb409a15d9babc78fe1d9957afcbaf1102cce58f is the first bad commit >

[committed] libstdc++: Fix condition for supported SIMD types on ARMv8

pushed to trunk, will backport tested on arm-linux-gnueabihf -- 8< -- Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/110050 * include/experimental/bits/simd.h (__vectorized_sizeof): With __have_neon_a32 only single-precision float

[PATCH][committed] aarch64: Add =r, m and =m, r alternatives to 64-bit vector move patterns

Hi all, We can use the X registers to load and store 64-bit vector modes, we just need to add the alternatives to the mov patterns. This straightforward patch does that and for the pair variants too. For the testcase in the code we now generate the optimal assembly without any superfluous

Re: [PATCH v5] tree-ssa-sink: Improve code sinking pass

On 1 June 2023 09:20:08 CEST, Ajit Agarwal wrote: >Hello All: > >This patch improves code sinking pass to sink statements before call to reduce >register pressure. >Review comments are incorporated. Hi Ajit! I had two comments for v4 that you did not address in v5 or followed up. thanks,

Re: [PATCH] RISC-V: Add pseudo vwmul.wv pattern to enhance vwmul.vv instruction optimizations

Hi， forget about this patch. Just go directly the V2 patch with same title. That's the last patch I fine tune for integer widening auto-vectorization. Thanks. juzhe.zh...@rivai.ai From: juzhe.zhong Date: 2023-06-01 15:31 To: gcc-patches CC: kito.cheng; kito.cheng; palmer; palmer;

[PATCH V2] RISC-V: Add pseudo vwmul.wv pattern to enhance vwmul.vv instruction optimizations

From: Juzhe-Zhong This patch is to enhance vwmul.vv combine optimizations. Consider this following code: void vwadd_int16_t_int8_t (int16_t *__restrict dst, int16_t *__restrict dst2, int16_t *__restrict dst3, int16_t *__restrict dst4, int8_t

Re: Re: [PATCH V3] VECT: Change flow of decrement IV

Thanks Kewen. Let's wait for Richard and Richi. juzhe.zh...@rivai.ai From: Kewen.Lin Date: 2023-06-01 13:24 To: juzhe.zh...@rivai.ai CC: richard.sandiford; rguenther; gcc-patches Subject: Re: [PATCH V3] VECT: Change flow of decrement IV Hi, on 2023/6/1 13:00, juzhe.zh...@rivai.ai wrote: >

[PATCH] Don't try bswap + rotate when TYPE_PRECISION(n->type) > n->range.

For the testcase in the PR, we have br64 = br; br64 = ((br64 << 16) & 0x00ffull) | (br64 & 0xff00ull); n->n: 0x300200. n->range: 32. n->type: uint64. The original code assumes n->range is same as TYPE PRECISION(n->type), and tries to rotate the mask from

[PATCH] RISC-V: Add pseudo vwmul.wv pattern to enhance vwmul.vv instruction optimizations

From: Juzhe-Zhong This patch is to enhance vwmul.vv combine optimizations. Consider this following code: void vwadd_int16_t_int8_t (int16_t *__restrict dst, int16_t *__restrict dst2, int16_t *__restrict dst3, int16_t *__restrict dst4, int8_t

  1   2   >