[PATCH 3/4] [RISC-V] resolve confilct between zcmp multi push/pop and shrink-wrap-separate

Disable zcmp multi push/pop if shrink-wrap-separate is active. So in -Os that prefers smaller code size, by default shrink-wrap-separate is disabled while zcmp multi push/pop is enabled. And in -O2 and others that prefers speed, by default shrink-wrap-separate is enabled while zcmp multi

[PATCH 4/4] [RISC-V] support cm.mva01s cm.mvsa01 in zcmp

From: Die Li Signed-off-by: Die Li Co-Authored-By: Fei Gao gcc/ChangeLog: * config/riscv/peephole.md: New pattern. * config/riscv/predicates.md (a0a1_reg_operand): New predicate. (zcmp_mv_sreg_operand): New predicate. * config/riscv/riscv.md: New predicate.

[PATCH 1/4][V4][RISC-V] support cm.push cm.pop cm.popret in zcmp

Zcmp can share the same logic as save-restore in stack allocation: pre-allocation by cm.push, step 1 and step 2. please be noted cm.push pushes ra, s0-s11 in reverse order than what save-restore does. So adaption has been done in .cfi directives in my patch. Signed-off-by: Fei Gao

[PATCH 2/4] [RISC-V] support cm.popretz in zcmp

Generate cm.popretz instead of cm.popret if return value is 0. Signed-off-by: Fei Gao gcc/ChangeLog: * config/riscv/riscv.cc (riscv_zcmp_can_use_popretz): true if popretz can be used (riscv_gen_multi_pop_insn): interface to generate cm.pop[ret][z]

[PATCH 0/4] [RISC-V] support zcmp extention

please be noted the series depend on the zcmp switch that Jiawei posted https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615289.html The 1st patch is a follow up on Kito's V3 review. Others are new. Fei Gao (4): [RISC-V] support cm.push cm.pop cm.popret in zcmp [RISC-V] support

[PATCH] rs6000: Remove redundant initialization [PR106907]

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 initialization of 'new_addr'. 2023-06-07 Jeevitha Palanisamy gcc/

Re: [committed] libstdc++: Update list of known symbol versions for abi-check

On 06/06/2023 17:59, Jonathan Wakely via Libstdc++ wrote: Tested x86_64-linux and powerpc64le-linux. Pushed to trunk. -- >8 -- Add the recently added CXXABI_1.3.15 version. Also remove two "frozen" versions from the latestp list, as no more symbols should be added to those now.

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

HI, + (VNx1SF "TARGET_VECTOR_ELEN_FP_16 && TARGET_MIN_VLEN < 128") + (VNx2SF "TARGET_VECTOR_ELEN_FP_16") + (VNx4SF "TARGET_VECTOR_ELEN_FP_16") + (VNx8SF "TARGET_VECTOR_ELEN_FP_16") + (VNx16SF "TARGET_VECTOR_ELEN_FP_16 && TARGET_MIN_VLEN > 32") + (VNx32SF "TARGET_VECTOR_ELEN_FP_16 &&

[PATCH v1] LoongArch:Change the default value of LARCH_CALL_RATIO to 6 on the LoongArch architecture.

During the regression testing of the LoongArch architecture GCC, it was found that the tests in the pr90883.C file failed. The problem was modulated and found that the error was caused by setting the macro LARCH_CALL_RATIO to a too large value. Combined with the actual LoongArch

RE: [PATCH] RISCV: Add -m(no)-omit-leaf-frame-pointer support.

Hi Jeff, Thanks your comments. I have few questions that I don't quite understand. > One of the things that needs to be upstreamed is long jump support within > a function. Essentially once a function reaches 1M in size we have the > real possibility that a direct jump may not reach its target.

RE: [PATCH] Handle FMA friendly in reassoc pass

Hello Lili Cui, Since I'm also trying to improve this lately, I've tested your patch on several aarch64 machines we have, including neoverse-n1 and ampere1 architectures. However, I haven't reproduced the 6.00% improvement of 503.bwaves_r single copy run you mentioned. Could you share more

Re: [PATCH] LoongArch: Change jumptable's register constraint to 'q' [PR110136]

在 2023/6/7 上午11:26, WANG Xuerui 写道: Hi, On 2023/6/7 10:31, Lulu Cheng wrote: If the $ra register is modified during the jump to the jump table, the hardware branch prediction function will be broken, resulting in a significant increase in the branch false prediction rate and affecting

Re: [PATCH] LoongArch: Change jumptable's register constraint to 'q' [PR110136]

Hi, On 2023/6/7 10:31, Lulu Cheng wrote: If the $ra register is modified during the jump to the jump table, the hardware branch prediction function will be broken, resulting in a significant increase in the branch false prediction rate and affecting performance. Thanks for the insight! This

Re: Re: [PATCH] RISC-V: Support RVV VLA SLP auto-vectorization

Hi, Thanks kito.. I have added comments as you suggested. >> Do we have check builder.npatterns () must be power of 2 in somewhere? I also added: /* We don't enable SLP for non-power of 2 NPATTERNS. */ if (!pow2p_hwi (d->perm.encoding().npatterns ())) return false; too. To make sure

[PATCH V2] RISC-V: Support RVV VLA SLP auto-vectorization

From: Juzhe-Zhong This patch enables basic VLA SLP auto-vectorization. Consider this following case: void f (uint8_t *restrict a, uint8_t *restrict b) { for (int i = 0; i < 100; ++i) { a[i * 8 + 0] = b[i * 8 + 7] + 1; a[i * 8 + 1] = b[i * 8 + 7] + 2; a[i * 8 + 2] = b[i *

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

On Tue, Jun 06, 2023 at 09:35:26PM +0200, FX Coudert wrote: > Hi Steve, > > I am not subscribed to the list (too little time, sadly), please keep me in > CC of your responses. > Unfortunately, fx is using a gmail account. Emails from my system to @gmail.com users are routinely and silently

RE: [PATCH v1] RISC-V: Refactor ZVFHMIN to separated iterator and pattern

Update the PATCH v3 with rvv.exp/riscv.exp all passed as below. https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620855.html Pan -Original Message- From: Gcc-patches On Behalf Of Li, Pan2 via Gcc-patches Sent: Tuesday, June 6, 2023 11:34 PM To: 钟居哲 ; gcc-patches Cc: kito.cheng ;

Re: [RFA] Improve strcmp expansion when one input is a constant string.

On 6/6/23 00:47, Richard Biener wrote: I wonder if there's some more generic target macro we can key the behavior off - SLOW_BYTE_ACCESS isn't a good fit, WORD_REGISTER_OPERATIONS is maybe closer but it's exact implications are unknown to me. Maybe there's something else as well ...

[PATCH v3] 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. The related define_insn and iterator will take the requirement based on the ZVFHMIN and ZVFH. Please note the ZVFH will cover the ZVFHMIN instructions. This patch add one test for this. Signed-off-by:

Re: [PATCH 2/2] Handle const_int in expand_single_bit_test

On 6/4/23 23:53, Andrew Pinski via Gcc-patches wrote: After expanding directly to rtl instead of creating a tree, we could end up with a const_int which is not ready to be handled by extract_bit_field. So need to the constant folding here instead. OK? bootstrapped and tested on

Re: [PATCH 1/2] Improve do_store_flag for single bit when there is no non-zero bits

On 6/4/23 23:53, Andrew Pinski via Gcc-patches wrote: In r14-1534-g908e5ab5c11c, I forgot you could turn off CCP or turn off the bit tracking part of CCP so we would lose out what TER was able to do before hand. This moves around the TER code so that it is used instead of just the

Re: [PATCH] For the `-A CMP -B -> B CMP A` pattern allow EQ/NE for all integer types

On 6/6/23 15:07, Andrew Pinski via Gcc-patches wrote: I noticed while looking at some code generation issue, that forwprop was not handling `-a == 0` for unsigned types and I was confused why it was not. r6-1814-g66e1cacf608045 removed these from fold because they were supposed to be already

Re: [PATCH] libiberty: writeargv: Simplify function error mode.

On 6/6/23 02:44, Costas Argyris wrote: You are right, this is also a remnant of the old function design that I completely missed.    Here is the follow-up patch for that. Thanks for pointing it out. Costas On Tue, 6 Jun 2023 at 04:12, Jeff Law > wrote:

Re: [PATCH] riscv: Fix scope for memory model calculation

On Mon, Jun 5, 2023 at 9:52 PM Dimitar Dimitrov wrote: > > During libgcc configure stage for riscv32-none-elf, when > "--enable-checking=yes,rtl" has been activated, the following error > is observed: > > configure:3814: > /home/dinux/projects/pru/local-workspace/riscv32-gcc-build/./gcc/xgcc

Re: [PATCH] riscv: Fix insn cost calculation

On 6/5/23 22:51, Dimitar Dimitrov wrote: When building riscv32-none-elf with "--enable-checking=yes,rtl", the following ICE is observed: cc1: internal compiler error: RTL check: expected code 'const_int', have 'const_double' in riscv_const_insns, at config/riscv/riscv.cc:1313 0x843c4d

Re: [PATCH] RISC-V: Support RVV VLA SLP auto-vectorization

Few comments, but all comments are asking adding more comment :P > @@ -398,6 +410,48 @@ rvv_builder::get_merge_scalar_mask (unsigned int > index_in_pattern) const >return gen_int_mode (mask, inner_int_mode ()); > } > > +/* Return true if the variable-length vector is single step. */ >

Re: [PATCH] riscv: Fix scope for memory model calculation

On 6/5/23 22:51, Dimitar Dimitrov wrote: During libgcc configure stage for riscv32-none-elf, when "--enable-checking=yes,rtl" has been activated, the following error is observed: configure:3814: /home/dinux/projects/pru/local-workspace/riscv32-gcc-build/./gcc/xgcc

Re: [PATCH 2/2] Add match patterns for `a ? onezero : onezero` where one of the two operands are constant

On 6/6/23 18:17, Andrew Pinski via Gcc-patches wrote: This adds a match pattern that are for boolean values that optimizes `a ? onezero : 0` to `a & onezero` and `a ? 1 : onezero` to `a | onezero`. This was reported a few times and I thought I would finally add the match pattern for this.

[PATCH] LoongArch: Change jumptable's register constraint to 'q' [PR110136]

If the $ra register is modified during the jump to the jump table, the hardware branch prediction function will be broken, resulting in a significant increase in the branch false prediction rate and affecting performance. gcc/ChangeLog: * config/loongarch/loongarch.md: Change register

RE: Re: [PATCH] RISC-V: Fix ICE when include riscv_vector.h with rv64gcv

Committed, thanks Kito and Juzhe. Pan From: juzhe.zh...@rivai.ai Sent: Wednesday, June 7, 2023 10:26 AM To: kito.cheng ; Li, Pan2 Cc: gcc-patches ; Kito.cheng ; Wang, Yanzhang ; Robin Dapp Subject: Re: Re: [PATCH] RISC-V: Fix ICE when include riscv_vector.h with rv64gcv LGTM.

Re: [PATCH 1/2] Match: zero_one_valued_p should match 0 constants too

On 6/6/23 18:17, Andrew Pinski via Gcc-patches wrote: While working on `bool0 ? bool1 : bool2` I noticed that zero_one_valued_p does not match on the constant zero as in that case tree_nonzero_bits will return 0 and that is different from 1. OK? Bootstrapped and tested on x86_64-linux-gnu

Re: Re: [PATCH] RISC-V: Fix ICE when include riscv_vector.h with rv64gcv

LGTM. juzhe.zh...@rivai.ai From: Kito Cheng Date: 2023-06-07 10:22 To: pan2.li CC: gcc-patches; juzhe.zhong; kito.cheng; yanzhang.wang; rdapp.gcc Subject: Re: [PATCH] RISC-V: Fix ICE when include riscv_vector.h with rv64gcv lgtm, thanks for fixing this :) On Wed, Jun 7, 2023 at 10:19 AM Pan

Re: [PATCH] RISC-V: Fix ICE when include riscv_vector.h with rv64gcv

lgtm, thanks for fixing this :) On Wed, Jun 7, 2023 at 10:19 AM Pan Li via Gcc-patches wrote: > > From: Pan Li > > This patch would like to fix the incorrect requirement of the vector > builtin types for the ZVFH/ZVFHMIN extension. The incorrect requirement > will result in the ops mismatch

[PATCH] RISC-V: Fix ICE when include riscv_vector.h with rv64gcv

From: Pan Li This patch would like to fix the incorrect requirement of the vector builtin types for the ZVFH/ZVFHMIN extension. The incorrect requirement will result in the ops mismatch with iterators, and then ICE will be triggered if ZVFH/ZVFHMIN is not given. Sorry for inconviensient.

Re: [PATCH] RISCV: Add -m(no)-omit-leaf-frame-pointer support.

On 6/4/23 20:49, Wang, Yanzhang wrote: Hi Jeff, Yes, there's a requirement to support backtrace based on the fp+ra. And the unwind/cfa is not acceptable because it will add additional sections to the binary. Currently, -fno-omit-frame-pointer can not save the ra for the leaf function. So we

[pushed] c++: NRV and goto [PR92407]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Here our named return value optimization was breaking the required destructor when the goto takes 'a' out of scope. The simplest fix is to disable the optimization in the presence of user labels. We could do better by disabling the

[pushed] c++: Add -Wnrvo

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While looking at PRs about cases where we don't perform the named return value optimization, it occurred to me that it might be useful to have a warning for that. This does not fix PR58487, but might be interesting to people watching it.

[pushed] c++: enable NRVO from inner block [PR51571]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Our implementation of the named return value optimization has been limited to variables declared in the outermost block of the function, to avoid needing to handle the case where the variable needs to be destroyed due to going out of scope.

[pushed] c++: fix throwing cleanup with label

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- While looking at PR92407 I noticed that the expectations of maybe_splice_retval_cleanup weren't being met; an sk_cleanup level was confusing its attempt to recognize the outer block of the function. And even if I fixed the detection, it

[pushed] c++: fix contracts with NRV

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The NRV implementation was blindly replacing the operand of RETURN_EXPR, clobbering anything that check_return_expr might have added on to the actual initialization, such as checking the postcondition. gcc/cp/ChangeLog: *

[pushed] c++: add NRV testcase [PR58050]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- This was fixed in GCC 10. PR c++/58050 gcc/testsuite/ChangeLog: * g++.dg/opt/nrv24.C: New test. --- gcc/testsuite/g++.dg/opt/nrv24.C | 18 ++ 1 file changed, 18 insertions(+) create mode 100644

Re: [PATCH V5] Use reg mode to move sub blocks for parameters and returns

Hi, On 2023-06-05 00:59, Jeff Law wrote: On 5/9/23 07:43, Jiufu Guo wrote: Thanks for point out this! Yes, BLKmode rtx may not always be a MEM. MEM_SIZE is only ok for MEM after the it's known size is computed. Here MEM_SIZE is fine just because it is an stack rtx corresponding to the type

Re: [PATCH] RISC-V: Support RVV VLA SLP auto-vectorization

Ping this patch. Ok for trunk ? Since following patches are blocked by this. juzhe.zh...@rivai.ai From: juzhe.zhong Date: 2023-06-06 12:16 To: gcc-patches CC: kito.cheng; kito.cheng; palmer; palmer; jeffreyalaw; rdapp.gcc; pan2.li; Juzhe-Zhong Subject: [PATCH] RISC-V: Support RVV VLA SLP

Re: [PATCH] Fold _mm{, 256, 512}_abs_{epi8, epi16, epi32, epi64} into gimple ABSU_EXPR + VCE.

On Tue, Jun 6, 2023 at 10:36 PM Uros Bizjak wrote: > > On Tue, Jun 6, 2023 at 1:42 PM Hongtao Liu wrote: > > > > On Tue, Jun 6, 2023 at 5:11 PM Uros Bizjak wrote: > > > > > > On Tue, Jun 6, 2023 at 6:33 AM liuhongt via Gcc-patches > > > wrote: > > > > > > > > r14-1145 fold the intrinsics into

[PATCH 1/2] Match: zero_one_valued_p should match 0 constants too

While working on `bool0 ? bool1 : bool2` I noticed that zero_one_valued_p does not match on the constant zero as in that case tree_nonzero_bits will return 0 and that is different from 1. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: * match.pd

[PATCH 2/2] Add match patterns for `a ? onezero : onezero` where one of the two operands are constant

This adds a match pattern that are for boolean values that optimizes `a ? onezero : 0` to `a & onezero` and `a ? 1 : onezero` to `a | onezero`. This was reported a few times and I thought I would finally add the match pattern for this. This hits a few times in GCC itself too. Notes on the

RE: [x86_64 PATCH] PR target/110104: Missing peephole2 for addcarry.

Hi Jakub, Jakub Jelinek wrote: > Seems to be pretty much the same as one of the 12 define_peephole2 patterns I've posted in https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620821.html Doh! Impressive work. I need to study how you handle constant carry flags. Fingers-crossed that patches

[x86 PATCH] PR target/31985: Improve memory operand use with doubleword add.

This patch addresses the last remaining issue with PR target/31985, that GCC could make better use of memory addressing modes when implementing double word addition. This is achieved by adding a define_insn_and_split that combines an *add3_doubleword with a *concat3, so that the components of

[r14-1579 Regression] FAIL: gfortran.dg/gomp/target-update-1.f90 -O scan-tree-dump gimple "#pragma omp target update to\\(c \\[len: [0-9]+\\]\\) to\\(present:a \\[len: [0-9]+\\]\\) to\\(e \\[len:

On Linux/x86_64, 4ede915d5dde935a16df2c6640aee5ab22348d30 is the first bad commit commit 4ede915d5dde935a16df2c6640aee5ab22348d30 Author: Tobias Burnus Date: Tue Jun 6 16:47:16 2023 +0200 openmp: Add support for the 'present' modifier caused FAIL: gfortran.dg/gomp/target-update-1.f90

Re: [x86_64 PATCH] PR target/110104: Missing peephole2 for addcarry.

On Tue, Jun 06, 2023 at 11:31:42PM +0100, Roger Sayle wrote: > > This patch resolves PR target/110104, a missed optimization on x86 around > adc with memory operands. In i386.md, there's a peephole2 after the > pattern for *add3_cc_overflow_1 that converts the sequence > reg = add(reg,mem); mem

[x86_64 PATCH] PR target/110104: Missing peephole2 for addcarry.

This patch resolves PR target/110104, a missed optimization on x86 around adc with memory operands. In i386.md, there's a peephole2 after the pattern for *add3_cc_overflow_1 that converts the sequence reg = add(reg,mem); mem = reg [where the reg is dead afterwards] into the equivalent mem =

Re: [PATCH] modula2: Fix bootstrap

Jakub Jelinek writes: > Hi! > > internal-fn.h since yesterday includes insn-opinit.h, which is a generated > header. > One of my bootstraps today failed because some m2 sources started compiling > before insn-opinit.h has been generated. > > Normally, gcc/Makefile.in has > # In order for

[PATCH] middle-end, i386: Pattern recognize add/subtract with carry [PR79173]

Hi! The following patch introduces {add,sub}c5_optab and pattern recognizes various forms of add with carry and subtract with carry/borrow, see pr79173-{1,2,3,4,5,6}.c tests on what is matched. Primarily forms with 2 __builtin_add_overflow or __builtin_sub_overflow calls per limb (with just one

[COMMITTED/13] Fix PR 110085: `make clean` in GCC directory on sh target causes a failure

On sh target, there is a MULTILIB_DIRNAMES (or is it MULTILIB_OPTIONS) named m2, this conflicts with the langauge m2. So when you do a `make clean`, it will remove the m2 directory and then a build will fail. Now since r0-78222-gfa9585134f6f58, the multilib directories are no longer created in

[PATCH] modula2: Fix bootstrap

Hi! internal-fn.h since yesterday includes insn-opinit.h, which is a generated header. One of my bootstraps today failed because some m2 sources started compiling before insn-opinit.h has been generated. Normally, gcc/Makefile.in has # In order for parallel make to really start compiling the

[PATCH] For the `-A CMP -B -> B CMP A` pattern allow EQ/NE for all integer types

I noticed while looking at some code generation issue, that forwprop was not handling `-a == 0` for unsigned types and I was confused why it was not. r6-1814-g66e1cacf608045 removed these from fold because they were supposed to be already handled by the match.pd patterns but it was missed that the

RE: [x86 PATCH] Add support for stc, clc and cmc instructions in i386.md

Hi Uros, Might you willing to approve the patch without the *x86_clc pieces? These can be submitted later, when they are actually used. For now, we're arguing about the performance of a pattern that's not yet generated on an obsolete microarchitecture that's no longer in use, and this is

[PATCH v6 3/4] c++modules: report imported CMI files as dependencies

They affect the build, so report them via `-MF` mechanisms. gcc/cp/ * module.cc (do_import): Report imported CMI files as dependencies. Signed-off-by: Ben Boeckel --- gcc/cp/module.cc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc

[PATCH v6 2/4] p1689r5: initial support

This patch implements support for [P1689R5][] to communicate to a build system the C++20 module dependencies to build systems so that they may build `.gcm` files in the proper order. Support is communicated through the following three new flags: - `-fdeps-format=` specifies the format for the

[PATCH v6 4/4] c++modules: report module mapper files as a dependency

It affects the build, and if used as a static file, can reliably be tracked using the `-MF` mechanism. gcc/cp/: * mapper-client.cc, mapper-client.h (open_module_client): Accept dependency tracking and track module mapper files as dependencies. * module.cc

[PATCH v6 1/4] libcpp: reject codepoints above 0x10FFFF

Unicode does not support such values because they are unrepresentable in UTF-16. libcpp/ * charset.cc: Reject encodings of codepoints above 0x10. UTF-16 does not support such codepoints and therefore all Unicode rejects such values. Signed-off-by: Ben Boeckel ---

[PATCH v6 0/4] P1689R5 support

Hi, This patch series adds initial support for ISO C++'s [P1689R5][], a format for describing C++ module requirements and provisions based on the source code. This is required because compiling C++ with modules is not embarrassingly parallel and need to be ordered to ensure that `import

Re: [PATCH] rs6000: Add builtins for IEEE 128-bit floating point values

On Mon, 2023-06-05 at 16:45 +0800, Kewen.Lin wrote: > Hi Carl, > > on 2023/5/2 23:52, Carl Love via Gcc-patches wrote: > > GCC maintainers: > > > > The following patch adds three buitins for inserting and extracting > > the > > exponent and significand for an IEEE 128-bit floating point > >

[PATCH ver 2] rs6000: Add builtins for IEEE 128-bit floating point values

Kewen, GCC maintainers: Version 2, I have addressed the various comments from Kewen. I had issues with adding an additional overloaded version of scalar_insert_exp with vector arguments. The overload infrastructure didn't work with a mix of scalar and vector arguments. I did rename the

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

Hi Steve, I am not subscribed to the list (too little time, sadly), please keep me in CC of your responses. > 1. You added fmin, fmax, and friends. Are these used >internally by gfortran in support of the IEEE_* >functions or are these exposed to the user? The math builtins are added

[PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

Hi, This is a repost of the patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html which never really got green light, but I stopped pushing because stage 1 was closing and I was out of time. It depends on a middle-end patch adding a type-generic __builtin_iseqsig(),

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

Hi, > I cannot see if there is proper support for kind=17 in your patch; > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not > seem to have any related code. Can real(kind=17) ever be an IEEE mode? If so, something seriously wrong happened, because the IEEE modules have no kind=17

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

On Thu, Jun 01, 2023 at 05:27:56PM +0100, Andre Vieira (lists) via Gcc-patches wrote: > --- a/gcc/internal-fn.h > +++ b/gcc/internal-fn.h > @@ -20,6 +20,10 @@ along with GCC; see the file COPYING3. If not see > #ifndef GCC_INTERNAL_FN_H > #define GCC_INTERNAL_FN_H > > +#include

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

Hi FX, On 6/6/23 15:19, FX via Gcc-patches wrote: Hi, This patch adds four IEEE functions from the Fortran 2018 standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, and IEEE_MAX_NUM_MAG. Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 and 64-bit. OK to commit? FX it would

[PATCH] c++: unsynthesized defaulted constexpr fn [PR110122]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- In the second testcase of PR110122, during regeneration of the generic lambda with V=Bar{}, substitution followed by coerce_template_parms for A's template argument naturally yields a copy of V in terms of

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

On Tue, Jun 06, 2023 at 08:51:54AM -0700, Steve Kargl via Fortran wrote: > > Scratch 2. Another scan shows that you moduled the Fortran s/you moduled/you added to > module where interface are built. This will automatically s/interface/interfaces > catch and report the items in 2. Complete

[PATCH] Add __builtin_iseqsig()

Hi, (It took me a while to get back to this.) This is a new and improved version of the patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html It addresses the comment from Joseph that FE_INVALID should really be tested in the case of both quiet and signaling NaNs, which

Re: [x86 PATCH] Add support for stc, clc and cmc instructions in i386.md

On Tue, Jun 6, 2023 at 5:14 PM Roger Sayle wrote: > > > Hi Uros, > This revision implements your suggestions/refinements. (i) Avoid the > UNSPEC_CMC by using the canonical RTL idiom for *x86_cmc, (ii) Use > peephole2s to convert x86_stc and *x86_cmc into alternate forms on > TARGET_SLOW_STC CPUs

[COMMITTED] reload1: Change return type of predicate function from int to bool

gcc/ChangeLog: * rtl.h (function_invariant_p): Change return type from int to bool. * reload1.cc (function_invariant_p): Change return type from int to bool and adjust function body accordingly. Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. Uros. diff --git

Re: [PATCH] rtl: AArch64: New RTL for ABD

Oluwatamilore Adebayo writes: >> It would be good to mark all of these functions with __attribute__((noipa)), >> since I think interprocedural optimisations might otherwise defeat the >> runtime test in abd_run_1.c (in the sense that we might end up folding >> things at compile time and not

Re: [PATCH v2] machine descriptor: New compact syntax for insn and insn_split in Machine Descriptions.

On 06/06/2023 13:49, Richard Sandiford via Gcc-patches wrote: Tamar Christina writes: int operand_number; /* Operand index in the big array. */ int output_format; /* INSN_OUTPUT_FORMAT_*. */ + bool compact_syntax_p; struct operand_data operand[MAX_MAX_OPERANDS];

Re: [Patch] libgomp: plugin-gcn - support 'unified_address'

On 06/06/2023 16:33, Tobias Burnus wrote: Andrew: Does the GCN change look okay to you? This patch permits to use GCN devices with 'omp requires unified_address' which in principle works already, except that the requirement handling did disable it. (It also updates libgomp.texi for this

[committed] libstdc++: Update list of known symbol versions for abi-check

Tested x86_64-linux and powerpc64le-linux. Pushed to trunk. -- >8 -- Add the recently added CXXABI_1.3.15 version. Also remove two "frozen" versions from the latestp list, as no more symbols should be added to those now. libstdc++-v3/ChangeLog: * testsuite/util/testsuite_abi.cc

[committed] libstdc++: Make std::numeric_limits<__float128> more portable [PR104772]

Tested x86_64-linux and powerpc64le-linux. Pushed to trunk. -- >8 -- This redefines std::numeric_limits<__float128> so that it works with non-GCC compilers. The previous definition didn't work with Clang, due to it not supporting __builtin_high_valq, __builtin_nanq, and __builtin_nansq. It also

Re: [PATCH] rs6000: Remove duplicate expression [PR106907]

Thanks for reviewing Segher. Will work on backports as well :). Jeevitha

Re: [PATCH] libstdc++: Rewrite or avoid casts to 64-bit element types

On Tue, 6 Jun 2023 at 15:14, Matthias Kretz via Libstdc++ < libstd...@gcc.gnu.org> wrote: > Last part to resolve test failure introduced with PR109822. > > OK for master and backports (gcc-11 doesn't have __builtin_shufflevector, > though)? > Yep, OK. > > Tested on x86_64-pc-linux-gnu and

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

On Tue, Jun 06, 2023 at 08:43:36AM -0700, Steve Kargl via Fortran wrote: > On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote: > > Hi, > > > > This patch adds four IEEE functions from the Fortran 2018 > > standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, > > and

Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions

On Tue, Jun 06, 2023 at 03:19:18PM +0200, FX via Fortran wrote: > Hi, > > This patch adds four IEEE functions from the Fortran 2018 > standard: IEEE_MIN_NUM, IEEE_MAX_NUM, IEEE_MIN_NUM_MAG, > and IEEE_MAX_NUM_MAG. > > Bootstrapped and regtested on x86_64-pc-linux-gnu, both 32 > and 64-bit. OK to

RE: [PATCH v1] RISC-V: Refactor ZVFHMIN to separated iterator and pattern

Update the PATCH V2 as below. https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620787.html Pan From: Li, Pan2 Sent: Tuesday, June 6, 2023 10:34 PM To: 钟居哲 ; gcc-patches Cc: kito.cheng ; Wang, Yanzhang Subject: RE: [PATCH v1] RISC-V: Refactor ZVFHMIN to separated iterator and pattern IMO,

[Patch] libgomp: plugin-gcn - support 'unified_address'

Andrew: Does the GCN change look okay to you? This patch permits to use GCN devices with 'omp requires unified_address' which in principle works already, except that the requirement handling did disable it. (It also updates libgomp.texi for this change and likewise for an older likewise nvptx

[PATCH v2] 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. The related define_insn and iterator will take the requirement based on the ZVFHMIN and ZVFH. Please note the ZVFH will cover the ZVFHMIN instructions. This patch add one test for this. Signed-off-by:

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

On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ < libstd...@gcc.gnu.org> wrote: > Tested x86_64-linux. I'd appreciate a second set of eyeballs on this > before I push it. > Pushed to trunk now. > > -- >8 -- > > This ensures that anything that depends on AC_REQUIRE is hoisted out of

Re: [PATCH] analyzer: Standalone OOB-warning [PR109437, PR109439]

On Tue, 2023-06-06 at 13:48 +0200, priour...@gmail.com wrote: > From: Benjamin Priour Hi Benjamin, thanks for this patch. Overall it look great. You didn't say what testing you did on the patch. Typically when preparing a patch for the mailing list we do a bootstrap build of gcc with the

RE: [PATCH V4] RISC-V: Add RVV vwmacc/vwmaccu/vwmaccsu combine lowering optmization

Committed, thanks Kito. Pan -Original Message- From: Gcc-patches On Behalf Of Kito Cheng via Gcc-patches Sent: Tuesday, June 6, 2023 10:45 PM To: juzhe.zh...@rivai.ai Cc: gcc-patches@gcc.gnu.org; pal...@rivosinc.com; rdapp@gmail.com; jeffreya...@gmail.com Subject: Re: [PATCH V4]

[PATCH 2/2] AArch64: New RTL for ABD

From: oluade01 This patch adds new RTL and tests for sabd and uabd PR tree-optimization/109156 gcc/ChangeLog: * config/aarch64/aarch64-simd-builtins.def (sabd, uabd): Change the mode to 3. * config/aarch64/aarch64-simd.md (aarch64_abd): Rename to abd3.

RE: [x86 PATCH] Add support for stc, clc and cmc instructions in i386.md

Hi Uros, This revision implements your suggestions/refinements. (i) Avoid the UNSPEC_CMC by using the canonical RTL idiom for *x86_cmc, (ii) Use peephole2s to convert x86_stc and *x86_cmc into alternate forms on TARGET_SLOW_STC CPUs (pentium4), when a suitable QImode register is available, (iii)

Re: [PATCH] rtl: AArch64: New RTL for ABD

> It would be good to mark all of these functions with __attribute__((noipa)), > since I think interprocedural optimisations might otherwise defeat the > runtime test in abd_run_1.c (in the sense that we might end up folding > things at compile time and not testing the vector versions of the

[PATCH, OpenACC 2.7] Implement default clause support for data constructs

Hi Thomas, this patch implements the OpenACC 2.7 addition of default(none|present) support for data constructs. Apart from adjusting the front-ends for allowed clauses masks (for acc data), mostly implemented in gimplify. Tested on powerpc64le-linux/nvptx, x86_64-linux/amdgcn tests in progress

[PATCH, OpenACC 2.7] Implement host_data must have use_device clause requirement

Hi Thomas, this patch implements the OpenACC 2.7 change requiring the host_data construct to have at least one use_device clause. This patch started out with a simple check during gimplify (much smaller patch), but turned out that front-ends removed use_device clauses when they have error, and

Re: [PATCH] c++: extend lookup_template_class shortcut [PR110122]

On 6/5/23 17:26, Patrick Palka wrote: Here when substituting the injected class name A during regeneration of the lambda, we find ourselves in lookup_template_class for A with V=_ZTAXtl3BarEE (i.e. the template parameter object for Foo{}). The call to coerce_template_parms within then

[committed] Re: [PATCHv2] openmp: Add support for 'present' modifier

Hi all, This adds OpenMP 5.1's 'present' modifier to the to/from/map clauses and 'defaultmap(present)'. I have now committed that patch as r14-1579-g4ede915d5dde935a16df2c6640aee5ab22348d30, or as attached. Or rather: I have done so after revising the patch for the issues I noted before;

Re: [PATCH V4] RISC-V: Add RVV vwmacc/vwmaccu/vwmaccsu combine lowering optmization

LGTM, we would like to improve that on the combine pass, but it could be improved later. On Tue, Jun 6, 2023 at 8:04 PM wrote: > > From: Juzhe-Zhong > > Fix according to comments from Robin of V1 patch. > > This patch add combine optimization for following case: > __attribute__ ((noipa)) void >

Re: [PATCH] Fold _mm{, 256, 512}_abs_{epi8, epi16, epi32, epi64} into gimple ABSU_EXPR + VCE.

On Tue, Jun 6, 2023 at 1:42 PM Hongtao Liu wrote: > > On Tue, Jun 6, 2023 at 5:11 PM Uros Bizjak wrote: > > > > On Tue, Jun 6, 2023 at 6:33 AM liuhongt via Gcc-patches > > wrote: > > > > > > r14-1145 fold the intrinsics into gimple ABS_EXPR which has UB for > > > TYPE_MIN, but PABSB will store

[PATCH 1/2] Missed opportunity to use [SU]ABD

From: oluade01 This adds a recognition pattern for the non-widening absolute difference (ABD). gcc/ChangeLog: * doc/md.texi (sabd, uabd): Document them. * internal-fn.def (ABD): Use new optab. * optabs.def (sabd_optab, uabd_optab): New optabs, *

RE: [PATCH v1] RISC-V: Refactor ZVFHMIN to separated iterator and pattern

IMO, TARGET_ZVFH || TARGET_ZVFHMIN may be a little readable compares to FP_16, or some context I missed. Anyway as we discussed offline, will refine this part and add zvfh part in V2. Pan From: 钟居哲 Sent: Tuesday, June 6, 2023 10:07 PM To: Li, Pan2 ; gcc-patches Cc: kito.cheng ; Li, Pan2 ;

  1   2   >