Re: [PATCH] mklog: fix bugs of --append option

Hi, Gentle Ping. I sent a V2 patch as below for an additional fix Python code format error, which Martin reported, thanks. Best, Lehua contrib/ChangeLog: * mklog.py: Fix bugs. --- contrib/mklog.py | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/contrib/mklo

Re: [PATCH v4] RISC-V: Fixbug for fsflags instruction error using immediate.

LGTM. Thanks for fixing it. juzhe.zh...@rivai.ai From: Jin Ma Date: 2023-07-26 13:41 To: gcc-patches CC: jeffreyalaw; palmer; richard.sandiford; kito.cheng; philipp.tomsich; christoph.muellner; rdapp.gcc; juzhe.zhong; jinma.contrib; Jin Ma Subject: [PATCH v4] RISC-V: Fixbug for fsflags instru

Re: [PATCH] Fix typo in insn name.

Hi Mike, on 2023/7/11 03:59, Michael Meissner wrote: > In doing other work, I noticed that there was an insn: > > vsx_extract_v4sf__load > > Which did not have an iterator. I removed the useless . It actually has a mode iterator, the "P" is used for clobber. The whole pattern of this de

[PATCH v4] RISC-V: Fixbug for fsflags instruction error using immediate.

The pattern mistakenly believes that fsflags can use immediate numbers, but in fact it does not support it. Immediate numbers should use fsflagsi. For example: __builtin_riscv_fsflags(4); The following error occurred. /tmp/ccoWdWqT.s: Assembler messages: /tmp/ccoWdWqT.s:14: Error: illegal operand

Re: Re: [PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

> So I guess you should change `fscsr` to `fscsr%i0` instead of dropping > K from the constraint list? > Sorry, you are right. I thought you were talking about fsflags, but I didn't notice it was fscsr. I'll correct it right away. > On Wed, Jul 26, 2023 at 11:42 AM juzhe.zh...@rivai.ai > wrote:

RE: [PATCH] RISC-V: Fix vector tuple intrinsic

Thanks a lot. I just fw one email about the write-after-approval steps. Pan -Original Message- From: Gcc-patches On Behalf Of juzhe.zh...@rivai.ai Sent: Wednesday, July 26, 2023 12:22 PM To: Li Xu ; gcc-patches Cc: kito.cheng ; palmer ; Li Xu Subject: Re: [PATCH] RISC-V: Fix vector t

Re: [PATCH] - Devirtualization of array destruction (C++) - 110057

On 7/12/23 10:10, Ng YongXiang via Gcc-patches wrote: Component: c++ Bug ID: 110057 Bugzilla link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057 Description: Array should not call virtual destructor of object when array is destructed ChangeLog: 2023-07-12 Ng YongXiang PR c++

Re: [PATCH] RISC-V: Fix vector tuple intrinsic

Thanks a lot for testing and fixing RVV API。 Could you add a simple float16 tuple api test ? I known the API is so big that we can't add all api tests into testsuite but adding a simple case will be nice. By the way, do you have write access? juzhe.zh...@rivai.ai From: Li Xu Date: 2023-07

[PATCH] RISC-V: Fix vector tuple intrinsic

Consider this following case: void test_vsoxseg3ei32_v_i32mf2x3(int32_t *base, vuint32mf2_t bindex, vint32mf2x3_t v_tuple, size_t vl) { return __riscv_vsoxseg3ei32_v_i32mf2x3(base, bindex, v_tuple, vl); } Compiler failed with: test.c:19:1: internal compiler error: in vl_vtype_info, at config/r

Re: Re: [PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

Yes. I agree. I didn't take a look into SPEC. Not sure whether fcsr has immediate form. I mean this patch change in 'fcsr' is quite confusing. You should either fix the assembly code-gen if fcsr has immediate form, or fix predicate and constraint both (should not fix constraint only). Thanks.

Re: Re: [PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

So I guess you should change `fscsr` to `fscsr%i0` instead of dropping K from the constraint list? On Wed, Jul 26, 2023 at 11:42 AM juzhe.zh...@rivai.ai wrote: > > I don't understand: > (define_insn "riscv_fscsr" > - [(unspec_volatile [(match_operand:SI 0 "csr_operand" "rK")] UNSPECV_FSCSR)] >

Re: Re: [PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

I don't understand: (define_insn "riscv_fscsr" - [(unspec_volatile [(match_operand:SI 0 "csr_operand" "rK")] UNSPECV_FSCSR)] + [(unspec_volatile [(match_operand:SI 0 "csr_operand" "r")] UNSPECV_FSCSR)] "TARGET_HARD_FLOAT || TARGET_ZFINX" "fscsr\t%0") This pattern never allows immediate in

Re: [PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

> - [(unspec_volatile [(match_operand:SI 0 "csr_operand" "rK")] UNSPECV_FSCSR)] > + [(unspec_volatile [(match_operand:SI 0 "csr_operand" "r")] UNSPECV_FSCSR)] > > If you don't allow immediate value in range 0 ~ 31, it should be > "register_operand" instead of "csr_operand". > > I think direc

Re: RISC-V: Folding memory for FP + constant case

On 7/25/23 05:24, Jivan Hakobyan wrote: Hi. I re-run the benchmarks and hopefully got the same profit. I also compared the leela's code and figured out the reason. Actually, my and Manolis's patches do the same thing. The difference is only execution order. But shouldn't your patch also all

Re: [PATCH] RISC-V: optim const DF +0.0 store to mem [PR/110748]

On 7/25/23 17:05, Palmer Dabbelt wrote: On Fri, 21 Jul 2023 11:47:58 PDT (-0700), gcc-patches@gcc.gnu.org wrote: On 7/21/23 12:31, Palmer Dabbelt wrote: (define_expand "len_mask_gather_load"    [(match_operand:VNX1_QHSD 0 "register_operand") -   (match_operand 1 "pmode_reg_or_0_operand") +  

[PATCH] rs6000: Correct vsx operands output for xxeval [PR110741]

Hi, PR110741 exposes one issue that we didn't use the correct character for vsx operands in output operand substitution, consequently it can map to the wrong registers which hold some unexpected values. Bootstrapped and regress-tested on powerpc64-linux-gnu P7/P8/P9 and powerpc64le-linux-gnu P9/P

[PATCH] vect: Treat VMAT_ELEMENTWISE as scalar load in costing [PR110776]

Hi, PR110776 exposes one issue that we could query unaligned load for vector type but actually no unaligned vector load is supported there. The reason is that the costed load is with single-lane vector type and its memory access type is VMAT_ELEMENTWISE, we actually take it as scalar load and set

Re: [PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

- [(unspec_volatile [(match_operand:SI 0 "csr_operand" "rK")] UNSPECV_FSCSR)] + [(unspec_volatile [(match_operand:SI 0 "csr_operand" "r")] UNSPECV_FSCSR)] If you don't allow immediate value in range 0 ~ 31, it should be "register_operand" instead of "csr_operand". juzhe.zh...@rivai.ai From

[PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

The pattern mistakenly believes that fsflags can use immediate numbers, but in fact it does not support it. Immediate numbers should use fsflagsi. For example: __builtin_riscv_fsflags(4); The following error occurred. /tmp/ccoWdWqT.s: Assembler messages: /tmp/ccoWdWqT.s:14: Error: illegal operand

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On 7/25/23 16:30, Marek Polacek wrote: On Tue, Jul 25, 2023 at 04:24:39PM -0400, Jason Merrill wrote: On 7/25/23 15:59, Marek Polacek wrote: Something like this, then? I see that cp_parser_initializer_clause et al offer further opportunities (because they sometimes use a dummy too) but this sh

Re: [PATCH] AArch64: Do not increase the vect reduction latency by multiplying count [PR110625]

> When was STMT_VINFO_REDUC_DEF empty? I just want to make sure that we're not > papering over an issue elsewhere. Yes, I also wonder if this is an issue in vectorizable_reduction. Below is the the gimple of "gcc.target/aarch64/sve/cost_model_13.c": : # res_18 = PHI # i_20 = PHI _1

Re: [PATCH v5 0/3] c++: Track lifetimes in constant evaluation [PR70331, ...]

On 7/22/23 11:12, Nathaniel Shead wrote: This is an update of the patch series at https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625050.html I applied the patches, with an addition to the first patch to fix constexpr-mutable3.C in C++11 mode, which was not part of the default std set. A

[pushed] testsuite: run C++11 tests in C++11 mode

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- A recent change missed updating constexpr-mutable3.C because it wasn't run in C++11 mode even though it checks the behavior for { target c++11_only }. gcc/testsuite/ChangeLog: * lib/g++-dg.exp (g++-dg-runtest): Check for c++11_only

Re: [gcc13 backport 12/12] riscv: fix error: control reaches end of non-void function

OK for backport :) On Wed, Jul 26, 2023 at 2:11 AM Patrick O'Neill wrote: > > From: Martin Liska > > Fixes: > gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void > function [-Werror=return-type] > 66 | [(set (attr "length") (const_int 4))]) >| ^ > > PR target/109

Re: [PATCH] RISC-V: optim const DF +0.0 store to mem [PR/110748]

On Fri, 21 Jul 2023 11:47:58 PDT (-0700), gcc-patches@gcc.gnu.org wrote: On 7/21/23 12:31, Palmer Dabbelt wrote: (define_expand "len_mask_gather_load"   [(match_operand:VNX1_QHSD 0 "register_operand") -   (match_operand 1 "pmode_reg_or_0_operand") +   (match_operand:P 1 "pmode_reg_or_0_operand"

[COMMITTED v2 1/2] bpf: don't print () in bpf_print_operand_address

[Changes from v1: save calls to fprintf] Unfortunately, the pseudo-C dialect syntax used for some of the v3 atomic instructions clashes with unconditionally printing the surrounding parentheses in bpf_print_operand_address. Instead, place the parentheses in the output templates where needed. gcc

[PATCH v2 2/2] bpf: add v3 atomic instructions

[Changes from v1: fix merge issue in invoke.texi] This patch adds support for the general atomic operations introduced in eBPF v3. In addition to the existing atomic add instruction, this adds: - Atomic and, or, xor - Fetching versions of these operations (including add) - Atomic exchange - At

Re: [PATCH 1/2] bpf: don't print () in bpf_print_operand_address

On 7/25/23 15:14, Jose E. Marchesi wrote: > > Hi David. > >> Unfortunately, the pseudo-C dialect syntax used for some of the v3 >> atomic instructions clashes with unconditionally printing the >> surrounding parentheses in bpf_print_operand_address. >> >> Instead, place the parentheses in the

Re: [PATCH 2/2] bpf: add v3 atomic instructions

On 7/25/23 15:18, Jose E. Marchesi wrote: > > Hi David. > >> +<<< HEAD > > There is a merge problem there. Ugh, I swear I've fixed this twice now. Yet it keeps cropping up. Sorry. v2 shortly. > >> @opindex mbswap >> @item -mbswap >> Enable byte swap instructions. Enabled for CPU v4

Re: [PATCH 2/2] bpf: add v3 atomic instructions

Hi David. > +<<< HEAD There is a merge problem there. > @opindex mbswap > @item -mbswap > Enable byte swap instructions. Enabled for CPU v4 and above. > @@ -24715,6 +24716,12 @@ Enable byte swap instructions. Enabled for CPU v4 > and above. > @item -msdiv > Enable signed division a

Re: [PATCH 1/2] bpf: don't print () in bpf_print_operand_address

Hi David. > Unfortunately, the pseudo-C dialect syntax used for some of the v3 > atomic instructions clashes with unconditionally printing the > surrounding parentheses in bpf_print_operand_address. > > Instead, place the parentheses in the output templates where needed. > > Tested in bpf-unknow

[PATCH 2/2] bpf: add v3 atomic instructions

This patch adds support for the general atomic operations introduced in eBPF v3. In addition to the existing atomic add instruction, this adds: - Atomic and, or, xor - Fetching versions of these operations (including add) - Atomic exchange - Atomic compare-and-exchange To control emission of t

[PATCH 1/2] bpf: don't print () in bpf_print_operand_address

Unfortunately, the pseudo-C dialect syntax used for some of the v3 atomic instructions clashes with unconditionally printing the surrounding parentheses in bpf_print_operand_address. Instead, place the parentheses in the output templates where needed. Tested in bpf-unknown-none. OK? gcc/

Re: [PATCH] match.pd: Implement missed optimization (~X | Y) ^ X -> ~(X & Y) [PR109986]

On Tue, Jul 25, 2023 at 1:54 PM Andrew Pinski wrote: > > On Tue, Jul 25, 2023 at 12:45 PM Jakub Jelinek via Gcc-patches > wrote: > > > > On Tue, Jul 25, 2023 at 03:42:21PM -0400, David Edelsohn via Gcc-patches > > wrote: > > > Hi, Drew > > > > > > Thanks for addressing this missed optimization.

[COMMITTED] Fix 110803: use of plain char instead of signed char

So the problem here is that plain char can either be signed or unsigned depending on the target (powerpc and aarch64 are unsigned while most other targets are signed). So the testcase gcc.c-torture/execute/pr109986.c was assuming plain char was signed char which is wrong so it is better to just cha

[patch] OpenMP: Call cuMemcpy2D/cuMemcpy3D for nvptx for omp_target_memcpy_rect

The attached patch calls CUDA's cuMemcopy2D and cuMemcpy3D for omp_target_memcpy_rect[,_async} for dim=2/dim=3. This should speed up the data transfer for noncontiguous data. While being there, I ended up adding support for device to other device copying; while potentially slow, it is still bette

Re: [gcc13 backport 00/12] RISC-V: Implement ISA Manual Table A.6 Mappings

On Tue, 25 Jul 2023 14:02:24 PDT (-0700), jeffreya...@gmail.com wrote: On 7/25/23 13:50, Jakub Jelinek wrote: On Tue, Jul 25, 2023 at 11:01:54AM -0700, Patrick O'Neill wrote: Discussed during the weekly RISC-V GCC meeting[1] and pre-approved by Jeff Law. If there aren't any objections I'll co

Re: [gcc13 backport 00/12] RISC-V: Implement ISA Manual Table A.6 Mappings

On 7/25/23 13:50, Jakub Jelinek wrote: On Tue, Jul 25, 2023 at 11:01:54AM -0700, Patrick O'Neill wrote: Discussed during the weekly RISC-V GCC meeting[1] and pre-approved by Jeff Law. If there aren't any objections I'll commit this cherry-picked series on Thursday (July 27th). Please don't

Re: [PATCH] match.pd: Implement missed optimization (~X | Y) ^ X -> ~(X & Y) [PR109986]

On Tue, Jul 25, 2023 at 12:45 PM Jakub Jelinek via Gcc-patches wrote: > > On Tue, Jul 25, 2023 at 03:42:21PM -0400, David Edelsohn via Gcc-patches > wrote: > > Hi, Drew > > > > Thanks for addressing this missed optimization. > > > > The testcase includes an incorrect assumption: signed char, whic

Re: [PATCH 1/2][frontend] Add novector C++ pragma

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

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On Tue, Jul 25, 2023 at 04:24:39PM -0400, Jason Merrill wrote: > On 7/25/23 15:59, Marek Polacek wrote: > > Something like this, then? I see that cp_parser_initializer_clause et al > > offer further opportunities (because they sometimes use a dummy too) but > > this should be a good start. > > Lo

Re: [PATCH] c++: clear tf_partial et al in instantiate_template [PR108960]

On 7/25/23 15:55, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- In we concluded that we might clear all flags except tf_warning_or_error when performing instantiate_template

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On 7/25/23 15:59, Marek Polacek wrote: On Fri, Jul 21, 2023 at 01:44:17PM -0400, Jason Merrill wrote: On 7/20/23 17:58, Marek Polacek wrote: On Thu, Jul 20, 2023 at 03:51:32PM -0400, Marek Polacek wrote: On Thu, Jul 20, 2023 at 02:37:07PM -0400, Jason Merrill wrote: On 7/20/23 14:13, Marek Po

Re: [gcc13 backport 00/12] RISC-V: Implement ISA Manual Table A.6 Mappings

On Tue, 25 Jul 2023 12:50:48 PDT (-0700), ja...@redhat.com wrote: On Tue, Jul 25, 2023 at 11:01:54AM -0700, Patrick O'Neill wrote: Discussed during the weekly RISC-V GCC meeting[1] and pre-approved by Jeff Law. If there aren't any objections I'll commit this cherry-picked series on Thursday (Jul

Re: [PATCH] c++: fix ICE with is_really_empty_class [PR110106]

On Fri, Jul 21, 2023 at 01:44:17PM -0400, Jason Merrill wrote: > On 7/20/23 17:58, Marek Polacek wrote: > > On Thu, Jul 20, 2023 at 03:51:32PM -0400, Marek Polacek wrote: > > > On Thu, Jul 20, 2023 at 02:37:07PM -0400, Jason Merrill wrote: > > > > On 7/20/23 14:13, Marek Polacek wrote: > > > > > On

Re: [gcc13 backport 00/12] RISC-V: Implement ISA Manual Table A.6 Mappings

On Tue, 25 Jul 2023 11:01:54 PDT (-0700), Patrick O'Neill wrote: Discussed during the weekly RISC-V GCC meeting[1] and pre-approved by Jeff Law. If there aren't any objections I'll commit this cherry-picked series on Thursday (July 27th). +Jakub According to the "GCC 13.1.1 Status Report (2023

[PATCH] c++: clear tf_partial et al in instantiate_template [PR108960]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- In we concluded that we might clear all flags except tf_warning_or_error when performing instantiate_template. PR c++/108960 gcc/cp/ChangeLog:

Re: [gcc13 backport 00/12] RISC-V: Implement ISA Manual Table A.6 Mappings

On Tue, Jul 25, 2023 at 11:01:54AM -0700, Patrick O'Neill wrote: > Discussed during the weekly RISC-V GCC meeting[1] and pre-approved by > Jeff Law. > If there aren't any objections I'll commit this cherry-picked series > on Thursday (July 27th). Please don't before 13.2 will be released, the bran

Re: [PATCH] match.pd: Implement missed optimization (~X | Y) ^ X -> ~(X & Y) [PR109986]

On Tue, Jul 25, 2023 at 03:42:21PM -0400, David Edelsohn via Gcc-patches wrote: > Hi, Drew > > Thanks for addressing this missed optimization. > > The testcase includes an incorrect assumption: signed char, which > causes the testcase to fail on PowerPC. > > Should the testcase be updated to spe

Re: [PATCH] match.pd: Implement missed optimization (x << c) >> c -> -(x & 1) [PR101955]

On Tue, Jul 25, 2023 at 03:25:57PM -0400, Drew Ross wrote: > > With that fixed I think for non-vector integrals the above is the most > suitable > > canonical form of a sign-extension. Note it should also work for any > other > > constant shift amount - just use the appropriate intermediate precis

Re: [PATCH] match.pd: Implement missed optimization (~X | Y) ^ X -> ~(X & Y) [PR109986]

Hi, Drew Thanks for addressing this missed optimization. The testcase includes an incorrect assumption: signed char, which causes the testcase to fail on PowerPC. Should the testcase be updated to specify signed char in the function signatures or should -fsigned-char be added to the command line

Re: [PATCH] match.pd: Implement missed optimization (x << c) >> c -> -(x & 1) [PR101955]

> With that fixed I think for non-vector integrals the above is the most suitable > canonical form of a sign-extension. Note it should also work for any other > constant shift amount - just use the appropriate intermediate precision for > the truncating type. > We _might_ want > to consider to onl

List myself as "nvptx port" maintainer (was: Thomas Schwinge appointed co-maintainer of the nvptx backend)

Hi! On 2023-07-19T23:41:47+0200, Gerald Pfeifer wrote: > It's my pleasure to announce Thomas Schwinge as co-maintainer of the > nvptx backend. > > Congratulations and Happy Hacking, Thomas! Please go ahead and update > MAINTAINERS accordingly. > > Gerald (on behalf of the steering committee) Tha

Re: [PATCH] range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755]

The frange bits look fine to me, so if you feel confident in the math logic, go right ahead :). Thanks. Aldy On 7/24/23 18:01, Jakub Jelinek wrote: Hi! IEEE754 says that x + (-x) and x - x result in +0 in all rounding modes but rounding towards negative infinity, in which case the result is -

[PATCH] Initialize value in bit_value_unop.

bit_value_binop initializes VAL regardless of the final mask. It even has a comment to that effect: /* Ensure that VAL is initialized (to any value). */ However, bit_value_unop, which in theory shares the same API, does not. This causes range-ops to choke on uninitialized VALs for some inputs

[COMMITTED] Make some functions in CCP static.

Committed as obvious. gcc/ChangeLog: * tree-ssa-ccp.cc (value_mask_to_min_max): Make static. (bit_value_mult_const): Same. (get_individual_bits): Same. --- gcc/tree-ssa-ccp.cc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/tree-ssa-ccp.cc b/

[PATCH] Replace invariant ternlog operands

Sometimes GCC generates ternlog with three operands, but some of them are invariant. For example: vpternlogq $252, %zmm2, %zmm1, %zmm0 In this case zmm1 register isnt used by ternlog. So should replace zmm1 with zmm0 or zmm2: vpternlogq $252, %zmm0, %zmm1, %zmm0 When the third operan

Re: [PATCH 2/1] c++: passing partially inst ttp as ttp [PR110566]

On 7/24/23 13:03, Patrick Palka wrote: On Fri, 21 Jul 2023, Jason Merrill wrote: On 7/21/23 14:34, Patrick Palka wrote: (This is a follow-up of https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624951.html) Bootstrapped and regtested on x86_64-pc-linux-gnu, how does this look? -- >8 -- The

[gcc13 backport 12/12] riscv: fix error: control reaches end of non-void function

From: Martin Liska Fixes: gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type] 66 | [(set (attr "length") (const_int 4))]) | ^ PR target/109713 gcc/ChangeLog: * config/riscv/sync.md: Add gcc_unreachable to a switch. --- gcc

[gcc13 backport 10/12] RISC-V: Weaken atomic loads

This change brings atomic loads in line with table A.6 of the ISA manual. 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/sync.md (atomic_load): Implement atomic load mapping. Signed-off-by: Patrick O'Neill --- gcc/config/riscv/sync.md | 28 ++

[gcc13 backport 11/12] RISC-V: Table A.6 conformance tests

These tests cover basic cases to ensure the atomic mappings follow the strengthened Table A.6 mappings that are compatible with Table A.7. 2023-04-27 Patrick O'Neill gcc/testsuite/ChangeLog: * gcc.target/riscv/amo-table-a-6-amo-add-1.c: New test. * gcc.target/riscv/amo-table-a-6

[gcc13 backport 07/12] RISC-V: Eliminate AMO op fences

Atomic operations with the appropriate bits set already enfore release semantics. Remove unnecessary release fences from atomic ops. This change brings AMO ops in line with table A.6 of the ISA manual. 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/riscv.cc (riscv_mem

[gcc13 backport 05/12] RISC-V: Add AMO release bits

This patch sets the relevant .rl bits on amo operations. 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/riscv.cc (riscv_print_operand): Change behavior of %A to include release bits. Signed-off-by: Patrick O'Neill --- gcc/config/riscv/riscv.cc | 7 ++- 1 file ch

[gcc13 backport 08/12] RISC-V: Weaken LR/SC pairs

Introduce the %I and %J flags for setting the .aqrl bits on LR/SC pairs as needed. Atomic compare and exchange ops provide success and failure memory models. C++17 and later place no restrictions on the relative strength of each model, so ensure we cover both by using a model that enforces the ord

[gcc13 backport 09/12] RISC-V: Weaken mem_thread_fence

This change brings atomic fences in line with table A.6 of the ISA manual. Relax mem_thread_fence according to the memmodel given. 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/sync.md (mem_thread_fence_1): Change fence depending on the given memory model. Signed-of

[gcc13 backport 06/12] RISC-V: Strengthen atomic stores

This change makes atomic stores strictly stronger than table A.6 of the ISA manual. This mapping makes the overall patchset compatible with table A.7 as well. 2023-04-27 Patrick O'Neill PR target/89835 gcc/ChangeLog: * config/riscv/sync.md (atomic_store): Use simple store

[gcc13 backport 02/12] RISC-V: Enforce Libatomic LR/SC SEQ_CST

Replace LR.aq/SC.rl pairs with the SEQ_CST LR.aqrl/SC.rl pairs recommended by table A.6 of the ISA manual. 2023-04-27 Patrick O'Neill libgcc/ChangeLog: * config/riscv/atomic.c: Change LR.aq/SC.rl pairs into sequentially consistent LR.aqrl/SC.rl pairs. Signed-off-by: Patrick O'N

[gcc13 backport 04/12] RISC-V: Enforce atomic compare_exchange SEQ_CST

This patch enforces SEQ_CST for atomic compare_exchange ops. Replace Fence/LR.aq/SC.aq pairs with SEQ_CST LR.aqrl/SC.rl pairs recommended by table A.6 of the ISA manual. 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/sync.md (atomic_cas_value_strong): Change FENCE/LR.

[gcc13 backport 03/12] RISC-V: Enforce subword atomic LR/SC SEQ_CST

Replace LR.aq/SC.rl pairs with the SEQ_CST LR.aqrl/SC.rl pairs recommended by table A.6 of the ISA manual. 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/sync.md: Change LR.aq/SC.rl pairs into sequentially consistent LR.aqrl/SC.rl pairs. Signed-off-by: Patrick O'Neill

[gcc13 backport 01/12] RISC-V: Eliminate SYNC memory models

Remove references to MEMMODEL_SYNC_* models by converting via memmodel_base(). 2023-04-27 Patrick O'Neill gcc/ChangeLog: * config/riscv/riscv.cc: Remove MEMMODEL_SYNC_* cases and sanitize memmodel input with memmodel_base. Signed-off-by: Patrick O'Neill --- gcc/config/riscv/r

[gcc13 backport 00/12] RISC-V: Implement ISA Manual Table A.6 Mappings

Discussed during the weekly RISC-V GCC meeting[1] and pre-approved by Jeff Law. If there aren't any objections I'll commit this cherry-picked series on Thursday (July 27th). Patchset on trunk: https://inbox.sourceware.org/gcc-patches/20230427162301.1151333-1-patr...@rivosinc.com/ First commit: f37

Re: [PATCH v3] c++: fix ICE with constexpr ARRAY_REF [PR110382]

On 7/25/23 12:59, Marek Polacek wrote: On Tue, Jul 25, 2023 at 11:15:07AM -0400, Jason Merrill wrote: On 7/24/23 18:37, Marek Polacek wrote: On Sat, Jul 22, 2023 at 12:28:59AM -0400, Jason Merrill wrote: On 7/21/23 18:38, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok

Re: [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

On Jul 19 2023, Xiao Zeng wrote: > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc > index 38d8eb2fcf5..7e6b24bd232 100644 > --- a/gcc/config/riscv/riscv.cc > +++ b/gcc/config/riscv/riscv.cc > @@ -2448,6 +2448,17 @@ riscv_rtx_costs (rtx x, machine_mode mode, int > outer_code, i

Re: [PATCH 0/5] Recognize Zicond extension

On 7/19/23 04:11, Xiao Zeng wrote: Hi all RISC-V folks: This series of patches completes support for the riscv architecture's Zicond standard extension instruction set. Currently, Zicond is in a frozen state. See the Zicond specification for details: https://github.com/riscv/riscv-zicond/re

Re: [PATCH 3/5] [RISC-V] Generate Zicond instruction for select pattern with condition eq or neq to 0

On 7/19/23 04:11, Xiao Zeng wrote: This patch completes the recognition of Zicond when the select pattern with condition eq or neq to 0 (using equality as an example), namely: 1 rd = (rs2 == 0) ? non-imm : 0 2 rd = (rs2 == 0) ? non-imm : non-imm 3 rd = (rs2 == 0) ? reg : non-imm 4 rd = (rs2 =

[PATCH v3] c++: fix ICE with constexpr ARRAY_REF [PR110382]

On Tue, Jul 25, 2023 at 11:15:07AM -0400, Jason Merrill wrote: > On 7/24/23 18:37, Marek Polacek wrote: > > On Sat, Jul 22, 2023 at 12:28:59AM -0400, Jason Merrill wrote: > > > On 7/21/23 18:38, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? > > > > >

Re: [PATCH 2/5] [RISC-V] Generate Zicond instruction for basic semantics

On 7/19/23 04:11, Xiao Zeng wrote: This patch completes the recognition of the basic semantics defined in the spec, namely: Conditional zero, if condition is equal to zero rd = (rs2 == 0) ? 0 : rs1 Conditional zero, if condition is non zero rd = (rs2 != 0) ? 0 : rs1 gcc/ChangeLog:

Re: [PATCH 1/5] [RISC-V] Recognize Zicond extension

On 7/19/23 04:11, Xiao Zeng wrote: This patch is the minimal support for Zicond extension, include the extension name, mask and target defination. gcc/ChangeLog: * common/config/riscv/riscv-common.cc: New extension. * config/riscv/riscv-opts.h (MASK_ZICOND): New mask.

New Ukrainian PO file for 'gcc' (version 13.1.0)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Ukrainian team of translators. The file is available at: https://translationproject.org/latest/gcc/uk.po (This file, 'gcc-13.1.0.uk.po', has

[PATCH, OpenACC 2.7] Connect readonly modifier to points-to analysis

On 2023/7/11 2:33 AM, Chung-Lin Tang via Gcc-patches wrote: > As we discussed earlier, the work for actually linking this to middle-end > points-to analysis is a somewhat non-trivial issue. This first patch allows > the language feature to be used in OpenACC directives first (with no effect > for

Re: [PATCH v2] c++: fix ICE with constexpr ARRAY_REF [PR110382]

On 7/24/23 18:37, Marek Polacek wrote: On Sat, Jul 22, 2023 at 12:28:59AM -0400, Jason Merrill wrote: On 7/21/23 18:38, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13? -- >8 -- This code in cxx_eval_array_reference has been hard to get right. In r12-2304 I

Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding

> The call fesetround could be any function in practice, and we never > know if that function might use dynamic rounding mode floating point > operation or not, also we don't know if it will be called fesetround > or not. > > So that's why we want to restore before function call to make sure we >

[PATCH] rtl-optimization/110587 - speedup find_hard_regno_for_1

The following applies a micro-optimization to find_hard_regno_for_1, re-ordering the check so we can easily jump-thread by using an else. This reduces the time spent in this function by 15% for the testcase in the PR. Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK if that passes? Tha

[PATCH] rtl-optimization/110587 - remove quadratic regno_in_use_p

The following removes the code checking whether a noop copy is between something involved in the return sequence composed of a SET and USE. Instead of checking for this special-case the following makes us only ever remove noop copies between pseudos - which is the case that is necessary for IRA/LR

[COMMITTED] Adjust one Ada test

Recent change modified how the loops are created, with the first iteration being extracted out of the loops in the 2 test cases. Adjust the text to match from the unroll dump. gcc/testsuite/ChangeLog: * gnat.dg/unroll3.adb: Adjust. --- Tested on x86_64-pc-linux-gnu, committed on master.

Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding

Hi Robin: Give few more context about the design: The call fesetround could be any function in practice, and we never know if that function might use dynamic rounding mode floating point operation or not, also we don't know if it will be called fesetround or not. So that's why we want to restore

Re: vectorizer: Avoid an OOB access from vectorization

Was leaving a bit of time in case Richi had any comments, but: Matthew Malcomson writes: > Our checks for whether the vectorization of a given loop would make an > out of bounds access miss the case when the vector we load is so large > as to span multiple iterations worth of data (while only bei

[PATCH] internal-fn: Refine macro define of COND_* and COND_LEN_* internal functions

From: Ju-Zhe Zhong Hi, Richard and Richi. Base on previous disscussions, we should make COND_* and COND_LEN_* consistent. So, this patch define these internal function together by these 2 wrappers: #ifndef DEF_INTERNAL_COND_FN #define DEF_INTERNAL_COND_FN(NAME, FLAGS, OPTAB, TYPE)

Re: [RFC] [v2] Extend fold_vec_perm to handle VLA vectors

Hi, Thanks for the rework and sorry for the slow review. Prathamesh Kulkarni writes: > Hi Richard, > This is reworking of patch to extend fold_vec_perm to handle VLA vectors. > The attached patch unifies handling of VLS and VLA vector_csts, while > using fallback code > for ctors. > > For VLS ve

Re: [PATCH] VECT: Support CALL vectorization for COND_LEN_*

"juzhe.zh...@rivai.ai" writes: > Hi, Richard. >>> I think we should have an internal-fn helper that returns IFN_COND_LEN_* >>> for a given IFN_COND_*. It could handle IFN_MASK_LOAD -> IFN_MASK_LEN_LOAD >>> etc. too. > Could you name this helper function for me? Does it call > "get_conditional_le

RE: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding

Thanks Robin. Let me share one example for the CALL scenario, considering below code. external int fesetround(int rounding_mode); test_call_for_rm: <-FRM X vfadd RTZ (static) <-FRM RTZ

Re: [PATCH] PR rtl-optimization/110587: Reduce useless moves in compile-time hog.

On Tue, Jul 25, 2023 at 1:31 PM Roger Sayle wrote: > > > This patch is the third in series of fixes for PR rtl-optimization/110587, > a compile-time regression with -O0, that attempts to address the underlying > cause. As noted previously, the pathological test case pr28071.c contains > a large n

Re: [COMMITTED] bpf: add pseudo-c asm dialect for "nop"

> The define_insn "nop" was missing a template for the pseudo-c dialect, > so the normal syntax was unconditionally emitted. Thank you. > Tested on bpf-unknown-none, committed as obvious. > > gcc/ > > * config/bpf/bpf.md (nop): Add pseudo-c asm dialect template. > --- > gcc/config/bpf/bp

[PATCH] PR rtl-optimization/110587: Reduce useless moves in compile-time hog.

This patch is the third in series of fixes for PR rtl-optimization/110587, a compile-time regression with -O0, that attempts to address the underlying cause. As noted previously, the pathological test case pr28071.c contains a large number of useless register-to-register moves that can produce qu

Re: Re: [PATCH] VECT: Support CALL vectorization for COND_LEN_*

Hi, Richard. >> I think we should have an internal-fn helper that returns IFN_COND_LEN_* >> for a given IFN_COND_*. It could handle IFN_MASK_LOAD -> IFN_MASK_LEN_LOAD >> etc. too. Could you name this helper function for me? Does it call "get_conditional_len_internal_fn_for_conditional_fn" ? Than

Re: [PATCH v3] x86: Properly find the maximum stack slot alignment

On Mon, Jul 24, 2023 at 10:36 PM H.J. Lu via Gcc-patches wrote: > > Don't assume that stack slots can only be accessed by stack or frame > registers. We first find all registers defined by stack or frame > registers. Then check memory accesses by such registers, including > stack and frame regis

Re: RISC-V: Folding memory for FP + constant case

Hi. I re-run the benchmarks and hopefully got the same profit. I also compared the leela's code and figured out the reason. Actually, my and Manolis's patches do the same thing. The difference is only execution order. Because of f-m-o held after the register allocation it cannot eliminate redunda

Re: [PATCH] Replace lra-spill.cc's return_regno_p with return_reg_p.

On Sat, Jul 22, 2023 at 6:45 PM Roger Sayle wrote: > > > This patch is my attempt to address the compile-time hog issue > in PR rtl-optimization/110587. Richard Biener's analysis shows that > compilation of pr28071.c with -O0 currently spends ~70% in timer > "LRA non-specific" due to return_regno

[patch] OpenMP/Fortran: Reject declarations between target + teams (was: [Patch] OpenMP/Fortran: Reject not strictly nested target -> teams [PR110725, PR71065])

On 24.07.23 21:49, Jakub Jelinek via Fortran wrote: On Mon, Jul 24, 2023 at 09:43:10PM +0200, Tobias Burnus wrote: This patch adds diagnostic for additional code alongside a nested teams in a target region. Thanks for working on this. The fuzzy thing on the Fortran side is if e.g. multiple nes

Re: [PATCH v2] RISC-V: Fixbug for fsflags instruction error using immediate.

Jin Ma via Gcc-patches 於 2023年7月25日 週二 15:29 寫道： > The pattern mistakenly believes that fsflags can use immediate numbers, > but in fact it does not support it. Immediate numbers should use fsflagsi. > > For example: > __builtin_riscv_fsflags(4); > > The following error occurred. > /tmp/ccoWdWqT.

  1   2   >