[PATCH] [RISC-V] c implies zca, and conditionally zcf & zcd

According to Zc-1.0.4-3.pdf from https://github.com/riscvarchive/riscv-code-size-reduction/releases/tag/v1.0.4-3 The rule is that: - C always implies Zca - C+F implies Zcf (RV32 only) - C+D implies Zcd Signed-off-by: Fei Gao gcc/ChangeLog: * common/config/riscv/riscv-common.cc:

Re: Re: [PATCH 2/2] [RISC-V] c implies zca, and conditionally zcf & zcd

On 2024-07-09 11:10  Kito Cheng wrote: > >LGTM, thanks :) > This patch still fails to apply in patchwork. Just realized it conflicts with a recent merge. So I rebased and resent a new patch.  Sorry to spam. BR Fei >On Tue, Jul 9, 2024 at 10:47 AM Fei Gao wrote: > >> According to Zc-1.0.4-3.pdf

[PATCH-1v5, rs6000] Implement optab_isinf for SFDF and IEEE128

Hi, This patch implemented optab_isinf for SFDF and IEEE128 by test data class instructions. Compared with previous version, the main changes are: 1 Define 3 mode attributes which are used for predicate, constraint and asm print selection. They help merge sp/dp/qp patterns to one. 2 Remove ori

Re: [PATCH v8 08/12] Give better error messages for musttail

On Mon, Jul 8, 2024 at 5:32 PM Andi Kleen wrote: > > On Mon, Jul 08, 2024 at 09:06:21AM +0200, Richard Biener wrote: > > On Sat, Jul 6, 2024 at 8:45 PM Andi Kleen wrote: > > > > > > > >if (!single_succ_p (bb)) > > > > > -return; > > > > > +{ > > > > > + int num_eh, num_other; > >

[PATCH] i386: Correct AVX10 CPUID emulation

Hi all, AVX10 Documentaion has specified ecx value as 0 for AVX10 version and vector size under 0x24 subleaf. Although for ecx=1, the bits are all reserved for now, we still need to specify ecx as 0 to avoid dirty value in ecx. Bootstrapped on x86-64-pc-linux-gnu. Ok for trunk and backport to GCC

Re: [PATCH] i386: Correct AVX10 CPUID emulation

On Tue, Jul 9, 2024 at 10:38 AM Haochen Jiang wrote: > > Hi all, > > AVX10 Documentaion has specified ecx value as 0 for AVX10 version and > vector size under 0x24 subleaf. Although for ecx=1, the bits are all > reserved for now, we still need to specify ecx as 0 to avoid dirty > value in ecx. > >

[committed] c: Rewrite c_parser_omp_tile_sizes to use c_parser_expr_list

Hi! The following patch simplifies c_parser_omp_tile_sizes to use c_parser_expr_list, so that it will get CPP_EMBED parsing naturally, without having another spot that needs to be adjusted for it. Tested on x86_64-linux, committed to trunk. 2024-07-09 Jakub Jelinek * c-parser.cc (c_p

[PATCH v2] c++/modules: Keep entity mapping info across duplicate_decls [PR99241]

On Mon, Jul 08, 2024 at 11:21:55AM -0400, Patrick Palka wrote: > On Mon, 8 Jul 2024, Nathaniel Shead wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14? > > > > -- >8 -- > > > > When duplicate_decls finds a match with an existing imported > > declaration, it clears D

Re: [RFC] Proposal to support Packed Boolean Vector masks.

On 7/8/24 4:45 PM, Richard Biener wrote: On Mon, Jul 8, 2024 at 11:27 AM Tejas Belagod wrote: Hi, Sorry to have dropped the ball on https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625535.html, but here I've tried to pick it up again and write up a strawman proposal for elevating __attribu

[v2][PATCH] RISC-V: fix zcmp popretz [PR113715]

No functional changes compared with V1, just spaces to table conversion in testcases to pass check-function-bodies. V1 passed regression locally but suprisingly failed in pre-commit CI, after picking the patch from patchwork, I realize table got coverted to spaces before sending the patch. Root c

[patch,avr] PR115830: Improve code by using more condition code

Hi Jeff, This patch adds peephole2s and insns to make better use of instructions that set condition code (SREG) as a byproduct. Of course with cc0 all this was *much* simpler... so here we go; adding CCNmode and CCZNmode, and extra insns that do arith + CC. No new regressions. Ok for master?

Re: [PATCH v3] Target-independent store forwarding avoidance.

On Mon, Jul 8, 2024 at 6:41 PM Andi Kleen wrote: > > > I have added a target hook for this in v4 of this patch. The hook > > receives all the information about the stores, the load, the estimated > > sequence cost and whether we expect to eliminate the load. With this > > information the target sh

Re: [PATCH] c++, contracts: Fix ICE in create_tmp_var [PR113968]

Hi Jason, On Mon, 8 Jul 2024 at 16:01, Jason Merrill wrote: > On 7/8/24 7:47 AM, Nina Dinka Ranns wrote: > > HI Jason, > > > > On Fri, 5 Jul 2024 at 17:31, Jason Merrill wrote: > >> > >> On 7/5/24 10:25 AM, Nina Dinka Ranns wrote: > >>> Certain places in contract parsing currently do not check

Re: [PATCH] c-family: Introduce the -Winvalid-noreturn flag from clang with extra tuneability

Hi Jason, Sorry for the long period of radio silence, but I'm finally done with all my university coursework. The main issue I see here is how to process the Winvalid-noreturn= entry. Can I define it in c.opt and then process it in c_common_handle_option and then store whether the -W or -Wno form

Re: [RFC] Proposal to support Packed Boolean Vector masks.

On Tue, Jul 9, 2024 at 11:45 AM Tejas Belagod wrote: > > On 7/8/24 4:45 PM, Richard Biener wrote: > > On Mon, Jul 8, 2024 at 11:27 AM Tejas Belagod wrote: > >> > >> Hi, > >> > >> Sorry to have dropped the ball on > >> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625535.html, but > >> here

[PATCH 1/3] lower SLP load permutation to interleaving

The following emulates classical interleaving for SLP load permutes that we are unlikely handling natively. This is to handle cases where interleaving (or load/store-lanes) is the optimal choice for vectorizing even when we are doing that within SLP. An example would be void foo (int * __restric

[PATCH 2/3] Support group-size of three in SLP load permutation lowering

The following adds support for group-size three in SLP load permutation lowering to match the non-SLP capabilities. This is done by using the non-interleaving fallback code which then creates at VF == 4 from { { a0, b0, c0 }, { a1, b1, c1 }, { a2, b2, c2 }, { a3, b3, c3 } } the intermediate vector

[PATCH 3/3] RISC-V: load and store-lanes with SLP

As promised this is the rework of SLP load/store-lane support with a simpler representation. It builds ontop the load-permute lowering series which I've squashed to two patches (already tested separately in the CI yesterday). The load/store-permute work hasn't seen much testing, I hope the CI w

[PATCH] testsuite: Tests the pattern folding x/sqrt(x) to sqrt(x) for Float16

As a follow-up to adding a pattern that folds x/sqrt(x) to sqrt(x) in match.pd, this patch adds a test case for type Float16 for armv8.2-a+fp16. The patch was bootstrapped and regtested on aarch64-linux-gnu, no regression. Ok for mainline? Signed-off-by: Jennifer Schmitz gcc/testsuite/ * gcc.

[PATCH 1/6] RISC-V: testsuite: Properly gate LTO tests

There are two test cases with the following skip directive: dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } This reads as: skip if both '-flto' and '-fno-fat-lto-objects' are present. This is not the case if only '-flto' is present. Since both tests depend on instruction sequences (one

[PATCH 2/6] RISC-V: Deduplicate arch subset list processing

We have a code duplication in riscv_set_arch_by_subset_list() and riscv_parse_arch_string(), where the latter function parses an ISA string into a subset_list before doing the same as the former function. riscv_parse_arch_string() is used to process command line options and riscv_set_arch_by_subse

[PATCH 0/6] RISC-V: Rewrite target arch attribute handling

As reported in PR 115554 and PR 115562, the current RISC-V target attribute handling code suffers from ICEs for legal inputs. An analysis of the code revealed deficits in the way target arch attributes are stored in the backend. This series attempts to address these issues. The first four commit

[PATCH 4/6] RISC-V: Fix comment/naming in attribute parsing code

Function target attributes have to be separated by semi-colons. Let's fix the comment and variable naming to better explain what the code does. gcc/ChangeLog: * config/riscv/riscv-target-attr.cc (riscv_process_target_attr): Fix comments and variable names. Signed-off-by: Christop

[PATCH 3/6] RISC-V: Attribute parser: Use alloca() instead of new + std::unique_ptr

Allocating an object on the heap with new, wrapping it in a std::unique_ptr and finally getting the buffer via buf.get() is a correct way to allocate a buffer that is automatically freed on return. However, a simple invocation of alloca() does the same with less overhead. gcc/ChangeLog:

[PATCH 5/6] RISC-V: Rewrite target attribute handling

The target-arch attribute handling in RISC-V is only a few months old, but already saw a rewrite (9941f0295a14), which addressed an important issue. This rewrite introduced a hash table in the backend, which is used to keep track of target-arch attributes of all functions. The index of this hash t

[PATCH 6/6] RISC-V: Allow adding enabled extension via target arch attributes

The set of enabled extensions can be extended via target arch function attributes by listing each extension with a '+' prefix and a comma as list separator. E.g.: __attribute__((target("arch=+zba,+zbb"))) void foo(); The programmer intends to ensure that one or more extensions are enabled when

Re: [PATCH 3/6] RISC-V: Attribute parser: Use alloca() instead of new + std::unique_ptr

IIRC Jeff mentions that it may introduce buffer overflow if the input string is long enough. On Tue, Jul 9, 2024 at 8:48 PM Christoph Müllner wrote: > > Allocating an object on the heap with new, wrapping it in a > std::unique_ptr and finally getting the buffer via buf.get() > is a correct way to

Re: [PATCH 4/6] RISC-V: Fix comment/naming in attribute parsing code

LGTM, that must be something I didn't update during...reference code from ARM :P On Tue, Jul 9, 2024 at 8:48 PM Christoph Müllner wrote: > > Function target attributes have to be separated by semi-colons. > Let's fix the comment and variable naming to better explain what > the code does. > > gcc

Re: [PATCH 1/6] RISC-V: testsuite: Properly gate LTO tests

LGTM On Tue, Jul 9, 2024 at 8:48 PM Christoph Müllner wrote: > > There are two test cases with the following skip directive: > dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } > This reads as: skip if both '-flto' and '-fno-fat-lto-objects' > are present. This is not the case if only '

Re: [PATCH 2/6] RISC-V: Deduplicate arch subset list processing

LGTM, thanks for simplifying this :) On Tue, Jul 9, 2024 at 8:48 PM Christoph Müllner wrote: > > We have a code duplication in riscv_set_arch_by_subset_list() and > riscv_parse_arch_string(), where the latter function parses an ISA string > into a subset_list before doing the same as the former f

Re: [PATCH 3/6] RISC-V: Attribute parser: Use alloca() instead of new + std::unique_ptr

On Tue, Jul 9, 2024 at 3:01 PM Kito Cheng wrote: > > IIRC Jeff mentions that it may introduce buffer overflow if the input > string is long enough. The manpage states: If the allocation causes stack overflow, program behavior is undefined. This was considered reasonable for AArch64: https://gc

[RFC] c++: Eagerly substitute auto constraint args in tsubst [PR115030]

Hi. While investigating a fix for C++/PR115030 (a bug in constrained auto deduction), I was wondering why we are not substituting constraint args of an auto node in tsubst (pt.cc:16533). Instead, this substitution is delayed until do_auto_deduction (pt.cc), where we attempt to find the substituted

[PATCH v1] c++: Eagerly substitute auto constraint args in tsubst [PR115030]

This patch addresses a bug in constrained auto deduction (C++/PR115030) by modifying tsubst to eagerly substitute the constraint args of an auto node. This change avoids the complexity of finding outer_targs during do_auto_deduction. Note that outer_targs cannot be completely removed but will be s

[PATCH v2 1/3] c++: Introduce USING_DECLs for non-function usings [PR114683]

On Mon, Jul 08, 2024 at 12:26:41PM -0400, Jason Merrill wrote: > On 7/6/24 10:06 PM, Nathaniel Shead wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > -- >8 -- > > > > With modules, a non-function using-declaration is not completely > > interchangable with the de

[PATCH v1] c++: Hash placeholder constraint in ctp_hasher

This patch addresses a difference between the hash function and the equality function for canonical types of template parameters (ctp_hasher). The equality function uses comptypes (typeck.cc) (with COMPARE_STRUCTURAL) and checks constraint equality for two auto nodes (typeck.cc:1586), while the has

[committed] arm: clean up some legacy FPA related cruft.

Support for the FPA on Arm was removed after gcc-4.7, but this little bit of crufty code was left behind. In particular the code to support the 'N' modifier in assembly code was left behind and this lead to a trail of other code that depended on it, even though most of the constants that it suppo

Re: [PATCH 2/3] c++/modules: Handle redefinitions of using-decls

On Mon, Jul 08, 2024 at 02:21:41PM -0400, Jason Merrill wrote: > On 7/6/24 10:07 PM, Nathaniel Shead wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > -- >8 -- > > > > This fixes an ICE exposed by supporting exported non-function > > using-decls. Sometimes when

Re: [PATCH 3/3] c++: Add locations to using_p OVERLOADs

On Mon, Jul 08, 2024 at 02:24:14PM -0400, Jason Merrill wrote: > On 7/6/24 10:13 PM, Nathaniel Shead wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > I have also been working on a patch that uses the locations of > > using-decls in 'diagnose_name_conflict' and 'd

Re: [PATCH 3/6] RISC-V: Attribute parser: Use alloca() instead of new + std::unique_ptr

On 7/9/24 7:12 AM, Christoph Müllner wrote: On Tue, Jul 9, 2024 at 3:01 PM Kito Cheng wrote: IIRC Jeff mentions that it may introduce buffer overflow if the input string is long enough. The manpage states: If the allocation causes stack overflow, program behavior is undefined. This wa

Re: [PATCH 6/6] RISC-V: Allow adding enabled extension via target arch attributes

LGTM, thanks for fixing this...and will take a detailed review on the remaining patch in the next few days :) On Tue, Jul 9, 2024 at 8:51 PM Christoph Müllner wrote: > > The set of enabled extensions can be extended via target arch function > attributes by listing each extension with a '+' prefi

Re: [v2][PATCH] RISC-V: fix zcmp popretz [PR113715]

On 7/9/24 4:00 AM, Fei Gao wrote: No functional changes compared with V1, just spaces to table conversion in testcases to pass check-function-bodies. V1 passed regression locally but suprisingly failed in pre-commit CI, after picking the patch from patchwork, I realize table got coverted to s

[pushed] diagnostics: use refs rather than pointers for diagnostic_{path, context}

Use const & rather than const * in various places where it can't be null and can't change. No functional change intended. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r15-1913-g2d6e6a77e840b7. gcc/ChangeLog: * diagnostic-path.cc: Replace "const diagno

[PATCH 1/2] rtl-ssa: Add replace_nondebug_insn [PR115785]

change_insns is used to change multiple instructions at once, so that the IR on return is valid & self-consistent. These changes can involve moving instructions, and the new position for one instruction might be expressed in terms of the old position of another instruction that is changing at the

Re: [PATCH] [RISC-V] c implies zca, and conditionally zcf & zcd

On 7/9/24 1:10 AM, Fei Gao wrote: According to Zc-1.0.4-3.pdf from https://github.com/riscvarchive/riscv-code-size-reduction/releases/tag/v1.0.4-3 The rule is that: - C always implies Zca - C+F implies Zcf (RV32 only) - C+D implies Zcd Signed-off-by: Fei Gao gcc/ChangeLog: * common

[PATCH 2/2] rtl-ssa: Fix prev_any_insn [PR115785]

Bit of a brown paper bag issue, but: due to the representation of the insn chain, insn_info::prev_any_insn would sometimes skip over instructions. This led to an invalid update in the PR when adding and removing instructions. I think one of the reasons I failed to spot this when checking the code

Re: [PATCH] [RISC-V] fix zcmp popretz [PR113715]

On 7/8/24 11:30 PM, Fei Gao wrote: On 2024-07-09 01:49  Jeff Law wrote: On 7/8/24 2:39 AM, Fei Gao wrote: Root cause: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b27d323a368033f0b37e93c57a57a35fd9997864 Commit above tries in targetm.gen_epilogue () to detect if there's li a0,0 insn at

Re: [PATCH 1/2] rtl-ssa: Add replace_nondebug_insn [PR115785]

On 7/9/24 9:28 AM, Richard Sandiford wrote: change_insns is used to change multiple instructions at once, so that the IR on return is valid & self-consistent. These changes can involve moving instructions, and the new position for one instruction might be expressed in terms of the old positio

[committed] i386: Implement .SAT_TRUNC for unsigned integers

The following testcase: unsigned short foo (unsigned int x) { _Bool overflow = x > (unsigned int)(unsigned short)(-1); return ((unsigned short)x | (unsigned short)-overflow); } currently compiles (-O2) to: foo: xorl%eax, %eax cmpl$65535, %edi seta%al negl%eax

Re: [PATCH] c++, coroutines, contracts: Handle coroutine and void functions [PR110871,PR110872,PR115434].

Hi Folks > On 8 Jul 2024, at 20:57, Jason Merrill wrote: > > On 7/8/24 3:37 PM, Iain Sandoe wrote: >>> On 8 Jul 2024, at 20:19, Jason Merrill wrote: >>> >>> On 6/17/24 8:15 AM, Iain Sandoe wrote: potentially_transformed_function_body (); } finally {

Re: [PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545]

On Sun, 23 Jun 2024, Martin Uecker wrote: > This fixes the test failures introduced by the fix for PR115109. > > Tested on x86_64 and also tested with -m32. > > > > Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545] > > Some tests added to test the type of red

Re: mve: Fix vsetq_lane for 64-bit elements with lane 1 [PR 115611]

Looks like I forgot to CC you Richard. But yeh ping :) On 26/06/2024 13:20, Andre Vieira (lists) wrote: This patch fixes the backend pattern that was printing the wrong input scalar register pair when inserting into lane 1. Added a new test to force float-abi=hard so we can use scan-assembler t

[PATCH] c++: Fix ICE on valid involving variadic constructor [PR111592]

We currently ICE upon the following valid code, due to the fix made through commit 9efe5fbde1e8 === cut here === struct ignore { ignore(...) {} }; template void InternalCompilerError(Args... args) { ignore{ ignore(args) ... }; } int main() { InternalCompilerError(0, 0); } === cut here === Change

Re: [PATCH] c: ICE with invalid sizeof [PR115642]

On Wed, 26 Jun 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > Here we ICE in c_expr_sizeof_expr on an erroneous expr.value. The > code checks for expr.value == error_mark_node but here the e_m_n is > wrapped in a C_MAYBE_CONST_EXPR. I do

Re: [PATCH] c: ICE on invalid with attribute optimize [PR115549]

On Thu, 27 Jun 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > I had this PR in my open tabs so why not go ahead and fix it. > > decl_attributes gets last_decl, the last already pushed declaration, > to be used in common_handle_aligned_att

Re: [PATCH] c: Add support for byte arrays in C2Y

On Sat, 29 Jun 2024, Martin Uecker wrote: > + bool typeless = flag_isoc2y > + && ((char_type_p (type) > + && !(type_quals & TYPE_QUAL_ATOMIC)) > + || (AGGREGATE_TYPE_P (type) > +

Re: [PATCH] c: Fix ICE for redeclaration of structs with different alignment [PR114727]

On Sat, 29 Jun 2024, Martin Uecker wrote: > This fixes an ICE when redeclaring a struct and having > an aligned attribute in one version in C23. > > > Bootstrapped and regression tested on x86_64. > > > > c: Fix ICE for redeclaration of structs with different alignment > [PR114727] >

Re: [PATCH] c: Fix ICE for incorrect code in comptypes_verify [PR115696]

On Sat, 29 Jun 2024, Martin Uecker wrote: > This adds missing code for handling error marks. > > > Bootstrapped and regression tested on x86_64. > > > > c: Fix ICE for incorrect code in comptypes_verify [PR115696] > > The new verification code produces an ICE for incorrect code.

[PATCH V2 0/2] Add support for B extention

Support for recognizing B as the collection of zba, zbb, zbs extensions https://github.com/riscv/riscv-b/tags V2: add b to riscv_combine_info Edwin Lu (2): RISC-V: Add support for B standard extension RISC-V: Update testsuite to use b gcc/common/config/riscv/riscv-common.cc | 7

[PATCH V2 1/2] RISC-V: Add support for B standard extension

This patch adds support for recognizing the B standard extension to be the collection of Zba, Zbb, Zbs extensions for consistency and conciseness across toolchains * https://github.com/riscv/riscv-b/tags gcc/ChangeLog: * common/config/riscv/riscv-common.cc: Add imply rules for B

Re: [PATCH] c: Add support for byte arrays in C2Y

Am Dienstag, dem 09.07.2024 um 17:28 + schrieb Joseph Myers: > On Sat, 29 Jun 2024, Martin Uecker wrote: > > > + bool typeless = flag_isoc2y > > + && ((char_type_p (type) > > +&& !(type_quals & TYPE_QUAL_ATOMIC)) > > +

[PATCH V2 2/2] RISC-V: Update testsuite to use b

Update all instances of zba_zbb_zbs in the testsuite to use b instead I doubt anything would happen but just re-running it through ci to make sure changes in first patch don't break anything here. gcc/testsuite/ChangeLog: * g++.target/riscv/redundant-bitmap-1.C: Use gcb instead of

[to-be-committed] [RISC-V] Improve bset generation for another case

So another minor improvement for bitmanip code generation. Essentially we have a pattern which matches a bset idiom for x = zero_extend (1 << n). That pattern only handles SI->DI extension. For the QI/HI case the 1

Re: [PATCH V2 1/2] RISC-V: Add support for B standard extension

On 7/9/24 11:44 AM, Edwin Lu wrote: This patch adds support for recognizing the B standard extension to be the collection of Zba, Zbb, Zbs extensions for consistency and conciseness across toolchains * https://github.com/riscv/riscv-b/tags gcc/ChangeLog: * common/config/riscv/riscv-

Re: [PATCH] RISC-V: Add basic support for the Zacas extension

On 7/8/24 13:36, Jeff Law wrote: On 7/8/24 1:25 PM, Patrick O'Neill wrote: https://gcc.gnu.org/onlinedocs/gccint/Machine-Independent-Predicates.html | Function: const_int_operand |     This predicate allows any CONST_INT expression that fits in mode. It is an appropriate choice for an i

Re: [PATCH] RISC-V: Add basic support for the Zacas extension

On 7/9/24 12:30 PM, Patrick O'Neill wrote: On 7/8/24 13:36, Jeff Law wrote: On 7/8/24 1:25 PM, Patrick O'Neill wrote: https://gcc.gnu.org/onlinedocs/gccint/Machine-Independent- Predicates.html | Function: const_int_operand |     This predicate allows any CONST_INT expression that fits

[PING*3][PATCH v2] rs6000: ROP - Do not disable shrink-wrapping for, leaf functions [PR114759]

Ping * 3. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>] Segher, this resolves the issues you mentioned in your review. Peter On 6/18/24 5:59 PM, Peter Bergner wrote: > Updated patch. This passed bootstrap and regtesting on powerpc64le-linux > with no regressions. Ok fo

[PATCH] rs6000: Error on CPUs and ABIs that don't support the ROP, protection insns [PR114759]

Hi Kewen, Here is that promised cleanup patch we discussed in the previous patch review. I'll note this patch is dependent on the previous patch you approved. I have not pushed that yet (in case you looked) since I'm waiting on Segher to approve the updated patch for not disabling shrink-wrapping

Re: [PATCH v2 1/3] c++: Introduce USING_DECLs for non-function usings [PR114683]

On 7/9/24 9:44 AM, Nathaniel Shead wrote: On Mon, Jul 08, 2024 at 12:26:41PM -0400, Jason Merrill wrote: For a using-decl in the same scope as the original decl, won't this replace it so only the using-decl is visible to lookup? I had expected to omit the USING_DECL in that case. Yup it will;

Re: [PATCH] c++, contracts: Fix ICE in create_tmp_var [PR113968]

On 7/9/24 6:41 AM, Nina Dinka Ranns wrote: On Mon, 8 Jul 2024 at 16:01, Jason Merrill > wrote: On 7/8/24 7:47 AM, Nina Dinka Ranns wrote: > HI Jason, > > On Fri, 5 Jul 2024 at 17:31, Jason Merrill mailto:ja...@redhat.com>> wrote: >> >> On 7/5

Re: [PATCH v2] c++/modules: Keep entity mapping info across duplicate_decls [PR99241]

On 7/9/24 5:16 AM, Nathaniel Shead wrote: Ah right, thanks for spotting that. That does make it look a bit cleaner; here's an updated patch. Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14? OK. -- >8 -- When duplicate_decls finds a match with an existing imported declar

Re: [PATCH] c++, coroutines, contracts: Handle coroutine and void functions [PR110871,PR110872,PR115434].

On 7/9/24 11:52 AM, Iain Sandoe wrote: Hi Folks On 8 Jul 2024, at 20:57, Jason Merrill wrote: On 7/8/24 3:37 PM, Iain Sandoe wrote: On 8 Jul 2024, at 20:19, Jason Merrill wrote: On 6/17/24 8:15 AM, Iain Sandoe wrote: potentially_transformed_function_body (); } finally

Re: [PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545]

Hello, Martin Uecker writes: > This fixes the test failures introduced by the fix for PR115109. > > Tested on x86_64 and also tested with -m32. > > > > Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545] > > Some tests added to test the type of redeclarations of

Re: [PATCH] Fix test errors introduced with fix for PR115157

Hello Martin, Martin Uecker writes: > BTW: Did you try the other testsuite patch as well? > > [PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) > [PR115545] I hadn't, but I did today and the patch is good from our CI's perspective. I replied directly to its email thread. --

[match.pd PATCH] PR tree-optimization/114661: Generalize MULT_EXPR recognition.

This patch resolves PR tree-optimization/114661, by generalizing the set of expressions that we canonicalize to multiplication. This extends the optimization(s) contributed (by me) back in July 2021. https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575999.html The existing transformation fold

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On 7/8/24 14:03, Jeff Law wrote: > > On 6/30/24 6:47 PM, Vineet Gupta wrote: >> Changes since v1: >>- Removed UNSPEC_{INFINITE,ISNORMAL} >>- Don't hardcode SI in patterns, try to keep X to avoid potential >> sign extension pitfalls. Implementation wise requires skipping >> :MODE s

Re: [PATCH] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On 7/1/24 06:42, Jeff Law wrote: >>> This works because those expanders are allowed to use FAIL. Some >>> expanders aren't allowed to do that (they're supposed to be documented >>> appropriately in the internals manual). >>> >>> In the matching define_insns, you can use X and adjust their names. >

Re: [PATCH] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On 7/3/24 12:08, Xi Ruoyao wrote: > On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote: >> I was also hoping to get __builtin_inf() done but unforutnately it >> requires little more rtl foo/bar to implement a tri-modal return. > Hmm do we really need to care the symbol? The generic __builtin_

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On 7/3/24 21:35, Xi Ruoyao wrote: > On Sun, 2024-06-30 at 17:47 -0700, Vineet Gupta wrote: >>   - Don't hardcode SI in patterns, try to keep X to avoid potential >>     sign extension pitfalls. Implementation wise requires skipping >>     :MODE specifier in match_operand which is flagged as missing

Re: [patch,avr] PR115830: Improve code by using more condition code

On 7/9/24 4:03 AM, Georg-Johann Lay wrote: Hi Jeff, This patch adds peephole2s and insns to make better use of instructions that set condition code (SREG) as a byproduct. Of course with cc0 all this was *much* simpler... so here we go; adding CCNmode and CCZNmode, and extra insns that do ari

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On 7/9/24 5:10 PM, Vineet Gupta wrote: On 7/3/24 21:35, Xi Ruoyao wrote: On Sun, 2024-06-30 at 17:47 -0700, Vineet Gupta wrote:   - Don't hardcode SI in patterns, try to keep X to avoid potential     sign extension pitfalls. Implementation wise requires skipping     :MODE specifier in mat

Re: [PATCH] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On 7/9/24 5:08 PM, Vineet Gupta wrote: On 7/3/24 12:08, Xi Ruoyao wrote: On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote: I was also hoping to get __builtin_inf() done but unforutnately it requires little more rtl foo/bar to implement a tri-modal return. Hmm do we really need to care

Re: [PATCH] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On 7/9/24 16:23, Jeff Law wrote: > > On 7/9/24 5:08 PM, Vineet Gupta wrote: >> On 7/3/24 12:08, Xi Ruoyao wrote: >>> On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote: I was also hoping to get __builtin_inf() done but unforutnately it requires little more rtl foo/bar to implement a

Re: [PATCH] Expand: Pass down equality only flag to cmpmem expand

On 11/28/23 12:43 AM, HAO CHEN GUI wrote: Hi, This patch passes down the equality only flags from emit_block_cmp_hints to cmpmem optab so that the target specific expand can generate optimized insns for equality only compare. Targets (e.g. rs6000) can generate more efficient insn sequence i

Re: [PATCH] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On 6/30/24 06:59, Jeff Law wrote: +;; TODO: isinf is a bit tricky as it require trimodal return +;; 1 if 0x80, -1 if 0x1, 0 otherwise >>> It shouldn't be terrible, but it's not trivial either. >>> >>> bext t0, a0, 0 >>> neg t0 >>> bext t1, a0, 7 >>> czero.nez res, t0, t1 >>> snez t1

Re: [PATCH] Add function filtering to gcov

On 6/25/24 1:56 AM, Jørgen Kvalsvik wrote: Add the --include and --exclude flags to gcov to control what functions to report on. This is meant to make gcov more practical as an when writing test suites or performing other coverage experiments, which tends to focus on a few functions at the tim

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

+CC Hao Chen Gui On 7/9/24 16:21, Jeff Law wrote:   - Don't hardcode SI in patterns, try to keep X to avoid potential     sign extension pitfalls. Implementation wise requires skipping     :MODE specifier in match_operand which is flagged as missing mode     warning. >>> I'

[PATCH] Remove expanding complex EQ/NE inside a GIMPLE_RETURN [PR115721]

This code has been dead at least since the move over to tuples in 0-88576-g726a989a8b74bf, when gimple returns could only have a simple expression in it. So let's remove it. Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: PR tree-optimization/115721

[PATCH] testsuite: Allow matching `{_1, { 0, 0, 0, 0 }}` for vect/slp-gap-1.c

While working on adding V4QI support to the aarch64 backend, vect/slp-gap-1.c started to fail but only because the regex was failing. Before it was loading use SI (int) and afterwards, we started to use V4QI. The generated code was the same and the generated gimple was almost the same. The regex wa

Re: [RFC/RFA] [PATCH 11/12] Replace the original CRC loops with a faster CRC calculation.

On 5/24/24 2:42 AM, Mariam Arutunian wrote:  Specifically, use the following alternatives: If the target  supports the crc32 instruction, use it directly. If the target supports the  carry-less multiplication instruction, use it to calculate the CRC. If the  target does not support eithe

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

Hi, 在 2024/7/10 8:04, Vineet Gupta 写道: > So it seems initial versions of the patch didn't specify anything about > output mode. Richi asked for it in review and in v4 Hao added it. > But I don't see anyone asking specifically for SImode. > I guess that can be relaxed. Hao do you have any inputs he

[PING^4][PATCH v2] rs6000: Fix issue in specifying PTImode as an attribute [PR106895]

Ping! Please review. Thanks & Regards Jeevitha On 19/06/24 6:12 pm, jeevitha wrote: > Ping! > > Please review. Are there any more changes required? > > Thanks & Regards > Jeevitha > > On 21/05/24 10:28 am, jeevitha wrote: >> Ping! >> >> please review. >> >> Thanks & Regards >> Jeevitha >> >>

Re: [PATCH] Expand: Pass down equality only flag to cmpmem expand

Hi Jeff, 在 2024/7/10 7:35, Jeff Law 写道: > Is this patch still relevant?  It was submitted after stage1 closed for > gcc-14.  With the trunk open for development, you should probably rebase and  > repost if the patch is still relevant/useful. > > Conceptually knowing that we just want to do an eq

Re: [PATCH] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On Tue, 2024-07-09 at 16:33 -0700, Vineet Gupta wrote: > > > On 7/9/24 16:23, Jeff Law wrote: > > > > On 7/9/24 5:08 PM, Vineet Gupta wrote: > > > On 7/3/24 12:08, Xi Ruoyao wrote: > > > > On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote: > > > > > I was also hoping to get __builtin_inf() d

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On Tue, 2024-07-09 at 16:10 -0700, Vineet Gupta wrote: > On 7/3/24 21:35, Xi Ruoyao wrote: > > On Sun, 2024-06-30 at 17:47 -0700, Vineet Gupta wrote: > > >   - Don't hardcode SI in patterns, try to keep X to avoid potential > > >     sign extension pitfalls. Implementation wise requires skipping >

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On 7/9/24 8:14 PM, Xi Ruoyao wrote: On Tue, 2024-07-09 at 16:10 -0700, Vineet Gupta wrote: On 7/3/24 21:35, Xi Ruoyao wrote: On Sun, 2024-06-30 at 17:47 -0700, Vineet Gupta wrote:   - Don't hardcode SI in patterns, try to keep X to avoid potential     sign extension pitfalls. Implementati

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On Mon, 2024-07-08 at 15:03 -0600, Jeff Law wrote: > So I would use tmp (or another word_mode pseudo register) for the > destination of that emit_insn.   Then something like: > >    t = gen_lowpart (SImode, tmp); >    SUBREG_PROMOTED_VAR_P (tmp) = 1; >    SUBREG_PROMOTED_SET (tmp, SRP

Re: [PATCH-1v5, rs6000] Implement optab_isinf for SFDF and IEEE128

Hi Haochen, on 2024/7/9 15:18, HAO CHEN GUI wrote: > Hi, > This patch implemented optab_isinf for SFDF and IEEE128 by test > data class instructions. > > Compared with previous version, the main changes are: > 1 Define 3 mode attributes which are used for predicate, constraint > and asm print

[committed][PATCH] RISC-V: backport fix zcmp popretz [PR113715]

Root cause: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b27d323a368033f0b37e93c57a57a35fd9997864 Commit above tries in targetm.gen_epilogue () to detect if there's li a0,0 insn at the end of insn chain, if so, cm.popret is replaced by cm.popretz and li a0,0 insn is deleted. Insertion of the gene

Re: [PATCH v2] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On 7/9/24 8:35 PM, Xi Ruoyao wrote: On Mon, 2024-07-08 at 15:03 -0600, Jeff Law wrote: So I would use tmp (or another word_mode pseudo register) for the destination of that emit_insn.   Then something like:    t = gen_lowpart (SImode, tmp);    SUBREG_PROMOTED_VAR_P (tmp) = 1;

Re: [PATCH] RISC-V: use fclass insns to implement isfinite and isnormal builtins

On 7/9/24 5:44 PM, Vineet Gupta wrote: On 6/30/24 06:59, Jeff Law wrote: +;; TODO: isinf is a bit tricky as it require trimodal return +;; 1 if 0x80, -1 if 0x1, 0 otherwise It shouldn't be terrible, but it's not trivial either. bext t0, a0, 0 neg t0 bext t1, a0, 7 czero.nez res, t0, t

  1   2   >