Re: [PATCH v2] RISC-V: Add svbare extension.

On 6/2/25 7:34 PM, Kito Cheng wrote: LGTM, and will commit once CI happy, BTW, next time you could name the testcase into arch-.c e.g. arch-svbare.c, that could prevent potential filename conflict. :) Yea, I nearly made a similar suggestion. Not sure why we're using numeric suffixes here. T

Re: [PATCH] RISC-V: Add Shlcofideleg extension.

On 5/27/25 1:32 AM, Jiawei wrote: This patch add the RISC-V Shlcofideleg extension. It supports delegating LCOFI interrupts(the count-overflow interrupts) to VS-mode.[1] [1] https://riscv.github.io/riscv-isa-manual/snapshot/privileged gcc/ChangeLog: * config/riscv/riscv-ext.def: New

Re: [PATCH] RISC-V: Add svbare extension.

On 5/29/25 7:27 AM, Dongyan Chen wrote: This patch support svbare extension, which is an extension in RVA23 profile. To enable GCC to recognize and process svbare extension correctly at compile time. Needs a ChangeLog entry and the testname needs to be updated now that arch-59 is taken. Wit

Re: [PATCH] RISC-V: Add smcntrpmf extension.

On 5/29/25 5:44 AM, Dongyan Chen wrote: This patch support smcntrpmf extension[1]. To enable GCC to recognize and process smcntrpmf extension correctly at compile time. [1]https://github.com/riscvarchive/riscv-smcntrpmf gcc/ChangeLog: * config/riscv/riscv-ext.def: New extension def

Re: [PATCH] Move get_call_rtx_from to final.c

On 6/1/25 1:12 AM, H.J. Lu wrote: Move get_call_rtx_from to final.c and call call_from_call_insn. PR other/120493 * final.cc (call_from_call_insn): Change the argument type to const rtx_call_insn *. (get_call_rtx_from): New. * rtl.h (is_a_helper ::test): New. (get_call_rtx_from): Moved to the

Re: [PING] [PATCH] vect: Improve vectorization for small-trip-count loops using subvectors

On 6/2/25 2:23 AM, Pengfei Li wrote: Hi all, I would like to bring attention back to this patch: https://inbox.sourceware.org/gcc-patches/20250508164950.5646-1-pengfei@arm.com/ The patch improves auto-vectorization for loops with known small trip counts by introducing a new target ho

Re: [PATCH] Add newlib to gitignore

On 6/2/25 3:01 AM, Arijit Kumar Das wrote: Hi, When compiling GCC for targets like nvptx-none that require newlib, we need to put newlib-cygwin/newlib in the root directory of the source tree (either a copy or a symlink), which is then built by GCC when targeting offload devices like the a

Re: [PATCH v5 05/24] Update is_function_default_version to work with target_version.

On 5/29/25 6:44 AM, Alfie Richards wrote: Notably this respects target_version semantics where an unannotated function can be the default version. gcc/ChangeLog: * attribs.cc (is_function_default_version): Add target_version logic. Approved by Richard Sandiford. Given this is approv

Re: [PATCH] expmed: Prevent non-canonical subreg generation in store_bit_field [PR118873]

On 5/30/25 12:12 AM, Richard Biener wrote: On Thu, May 29, 2025 at 12:27 PM Konstantinos Eleftheriou wrote: Hi Richard, thanks for the response. On Mon, May 26, 2025 at 11:55 AM Richard Biener wrote: On Mon, 26 May 2025, Konstantinos Eleftheriou wrote: In `store_bit_field_1`, when the

Re: [PATCH v5 07/24] Change make_attribute to take string_slice.

On 5/29/25 6:46 AM, Alfie Richards wrote: gcc/ChangeLog: * attribs.cc (make_attribute): Change arguments. * attribs.h (make_attribute): Change arguments. Approved by Richard Sandiford. Similarly for anything else already approved that is safe to commit now. jeff

Re: [PATCH] testsuite: Add tls_link effective target

On 5/27/25 7:36 AM, Christophe Lyon wrote: Some tests have 'dg-do link' but currently require 'tls' which is a compile-only check. In some configurations of arm-none-eabi, the 'tls' effective-target can be successful although these tests fail to link with undefined reference to `__aeabi_read_

Re: [PATCH 0/3] Redirect to specific target based on TARGET_VERSION_COMPATIBLE

On 5/28/25 3:58 AM, Alfie Richards wrote: On 28/05/2025 03:36, Jeff Law wrote: On 5/27/25 2:36 AM, Alfie Richards wrote: Hi Jeff, On 22/05/2025 21:02, Jeff Law wrote: On 5/22/25 9:05 AM, Alfie Richards wrote: Hi Jeff, I sent this patch with my implementation a while ago: https

Re: [PATCH] RISC-V: Adjust build rule for gen-riscv-ext-opt and gen-riscv-ext-texi

On 5/28/25 11:59 PM, Kito Cheng wrote: Separate the build rules to compile and link stage to make sure BUILD_LINKERFLAGS and BUILD_LDFLAGS are applied correctly. We hit this issue when we try to build GCC with non-system-default g++, and it use newer libstdc++, and then got error from using o

Re: [PATCH] or1k: Fix struct return test

On 5/31/25 12:03 AM, Stafford Horne wrote: In or1k structs are returned from functions using the memory address passed in r3. In the current version of GCC the struct stores changed from r11 (the return value) to r3 the incoming memory address. Both of are valid. Adjust the test to match wh

Re: [PATCH] Add newlib to gitignore

On 6/1/25 1:40 PM, Arijit Kumar Das wrote: newlib sources are not a part of GCC so should be ignored, if present. Signed-off-by: Arijit Kumar Das --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 7150fc3b29c..5ae6a5a08d6 100644 --- a/.giti

Re: [PATCH] testsuite: RISC-V: Fix the typo in param-autovec-mode.c

On 5/28/25 7:59 PM, Liao Shihua wrote: This patch fixes the typo in the test case `param-autovec-mode.c` in the RISC-V autovec testsuite. The option `autovec-mode` is changed to `riscv-autovec-mode` to match the expected parameter name. gcc/testsuite/ChangeLog: * gcc.target/riscv

Re: DEFAULT_PCC_STRUCT_RETURN on NetBSD vs Linux

On 6/1/25 8:21 AM, John Paul Adrian Glaubitz wrote: And what about the value for STACK_BOUNDARY? It seems to be 16 for many Linux targets while it's 32 for NetBSD. Is there a reason why it's 16-bit- aligned on Linux? Regardless of differences in the values, I don't see changing them at this

Re: [PATCH v4 04/20] Remove unnecessary `record` argument from maybe_version_functions.

On 5/28/25 4:10 AM, Alfie Richards wrote: Previously, the `record` argument in maybe_version_function allowed the call to cgraph_node::record_function_versions to be skipped. However, this was only skipped when both decls were already marked as versioned, in which case we trigger the early ex

Re: [PATCH v4 03/20] Add string_slice class.

On 5/28/25 4:10 AM, Alfie Richards wrote: The string_slice inherits from array_slice and is used to refer to a substring of an array that is memory managed elsewhere without modifying the underlying array. For example, this is useful in cases such as when needing to refer to a substring of an

Re: [PATCH] RISC-V: Add 'bclr+binv' peephole2 optimization.

On 5/28/25 9:05 PM, Jiawei wrote: This seems like it would be much better as a combine pattern.   In fact, I'm a bit surprised that combine didn't simplify this series of operations into a IOR.  So I'd really like to see the .combine dump with and without this hunk for the relevant testcas

Re: [PATCH v5 02/24] i386: Add x86 FMV symbol tests

On 5/29/25 6:40 AM, Alfie Richards wrote: From: Alice Carlotti This is for testing the x86 mangling of FMV versioned function assembly names. gcc/testsuite/ChangeLog: * g++.target/i386/mv-symbols1.C: New test. * g++.target/i386/mv-symbols2.C: New test. * g++.target/

Re: [PATCH v5 01/24] ppc: Add PowerPC FMV symbol tests.

On 5/29/25 6:40 AM, Alfie Richards wrote: From: Alice Carlotti This tests the mangling of function assembly names when annotated with target_clones attributes. gcc/testsuite/ChangeLog: * g++.target/powerpc/mvc-symbols1.C: New test. * g++.target/powerpc/mvc-symbols2.C: New t

Re: [PATCH] RISC-V: Add 'bclr+binv' peephole2 optimization.

On 5/28/25 4:23 AM, Jiawei wrote: This patch adds a peephole2 optimization that combines a 'bclr' followed by a 'binv' into a single 'bset' instruction when the Zbs extension is enabled. The motivation for this patch is that PR116398 limits 2→2 RTL combinations, which prevents certain simplif

Re: [PATCH 0/3] Redirect to specific target based on TARGET_VERSION_COMPATIBLE

On 5/27/25 2:36 AM, Alfie Richards wrote: Hi Jeff, On 22/05/2025 21:02, Jeff Law wrote: On 5/22/25 9:05 AM, Alfie Richards wrote: Hi Jeff, I sent this patch with my implementation a while ago: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681043.html There hasn't bee

Re: [PATCH 0/3] Redirect to specific target based on TARGET_VERSION_COMPATIBLE

On 5/22/25 9:26 PM, Yangyu Chen wrote: On 23 May 2025, at 04:02, Jeff Law wrote: On 5/22/25 9:05 AM, Alfie Richards wrote: Hi Jeff, I sent this patch with my implementation a while ago: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681043.html There hasn't been any feedba

Re: [PATCH v1 1/3] RISC-V: Leverage vaadd.vv for signed standard name avg_floor

On 5/27/25 12:27 AM, Robin Dapp wrote: Apart from that it LGTM, thanks for digging deeper here. Just wanted to echo this. I've had a low priority todo to review vaaddu and friends after seeing them get used in some hand coded versions of various routines in x264. Even if you're not tackl

[to-be-committed][RISC-V] Add andi+bclr synthesis

So this patch from Shreya adds the ability to use andi + a series of bclr insns to synthesize a logical AND, much like we're doing for IOR/XOR using ori+bset or their xor equivalents. This would regress from a code quality standpoint if we didn't make some adjustments to a handful of define_in

[to-be-committed][RISC-V] shift+and+shift for logical and synthesis

The next chunk of Shreya's work. For this expansion we want to detect cases when the mask fits in a simm12 after shifting right by the number of trailing zeros in the mask. In that case we can synthesize the AND with a shift right, andi and shift left. I saw this case come up when doing some

Re: [PATCH 2/2] VR-VALUES: Rewrite test_for_singularity using range_op_handler

On 5/23/25 8:56 AM, Andrew MacLeod wrote: Since the PR scrolled by, i don't think I ever noticed this thread.. or at least where it lead. This is not an "equivalence" that ranger would propagate because its a relation with a constant. the issue here seems to be: if (x < 4)   when x has

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

On 5/22/25 6:12 AM, Robin Dapp wrote: AFAICT the main difference to standard mode switching is that we (ab)use it to set the rounding mode to the value it had initially, either at function entry or after a call.  That's different to regular mode switching which assumes "static" rounding mode

Re: [PATCH 0/3] Redirect to specific target based on TARGET_VERSION_COMPATIBLE

On 5/22/25 9:05 AM, Alfie Richards wrote: Hi Jeff, I sent this patch with my implementation a while ago: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681043.html There hasn't been any feedback on that patch yet. These patches are still useful and I would like to go ahead with them.

Re: [PATCH][RISC-V][PR target/70557] Improve storing 0 to memory on rv32

On 5/21/25 11:41 PM, Shreya Munnangi wrote: Patch is originally from Siarhei Volkau >. RISC-V has a zero register (x0) which we can use to store zero into memory without loading the constant into a distinct register. Adjust the constraints of the 32-bit movdi_32bit

Re: [PATCH] RISC-V: Add minimal support of double trap extension 1.0

On 5/22/25 12:21 AM, Jerry Zhang Jian wrote: Add support of double trap extension [1], enabling GCC to recognize the following extensions at compile time. New extensions: - ssdbltrp - smdbltrp [1] https://github.com/riscv/riscv-double-trap/releases/download/v1.0/riscv-double-trap.

Re: [PATCH] libgcc: PR target/116363 Fix SFtype to UDWtype conversion

On 5/22/25 1:01 AM, Jan Dubiec wrote: On 23.02.2025 04:59, Jeff Law wrote: [...] Thanks!  Just a note we're in stage4 of our development cycle (regression bugfixes) as we prepare for gcc-15.  This doesn't look like something we would typically make an exception for, it'll ha

Re: [PATCH] testsuite: RISC-V: Update the cset-sext-sfb/zba-slliuw test optimization level.

On 5/21/25 9:16 PM, Dongyan Chen wrote: Failed testcases occurred in the regression test of gcc: cset-sext-sfb.c failed the -Oz test, and zba-slliuw.c failed the -Og test. This patch solves the problem by skipping the optimization. gcc/testsuite/ChangeLog: * gcc.target/riscv/cset-sex

Re: [PATCH 0/3] Redirect to specific target based on TARGET_VERSION_COMPATIBLE

On 4/14/25 5:34 AM, Yangyu Chen wrote: On 14 Apr 2025, at 19:06, Alfie Richards wrote: Hi Yangyu, This looks great with what we discussed previously. I have a very similar patch that implements a slightly stronger optimisation that I was about to send. It makes use of information if th

Re: [PATCH] match: Undo maybe_push_res_to_seq in some cases [PR120331]

On 5/18/25 10:38 AM, Andrew Pinski wrote: While working on improving forwprop and removal of forward_propagate_into_gimple_cond/forward_propagate_into_comparison, I came cross a case where we end up with SSA_NAME in the resulting gimple_match_op and one statement in the sequence. This was the

[to-be-committed][RISC-V] Clear both upper and lower bits using 3 shifts

So the next step in Shreya's work. In the prior patch we used two shifts to clear bits at the high or low end of an object. In this patch we use 3 shifts to clear bits on both ends. Nothing really special here. With mvconst_internal still in the tree it's of marginal value, though Shreya an

Re: [PATCH 1/2] expand: Use rtx_cost directly instead of gen_move_insn for canonicalize_comparison.

On 5/20/25 9:12 PM, Andrew Pinski wrote: This is the first part in fixing PR target/120372. The current code for canonicalize_comparison, uses gen_move_insn and rtx_cost to find out the cost of generating a constant. This is ok in most cases except sometimes the comparison instruction can han

Re: [PATCH] configure: Always add pre-installed header directories to search path

On 9/25/24 9:22 PM, Stephanos Ioannidis wrote: configure script was adding the target directory flags, including the '-B' flags for the executable prefix and the '-isystem' flags for the pre-installed header directories, to the target flags only for non-Canadian builds under the premise that t

Re: [PATCH] combine: gen_lowpart_no_emit vs CLOBBER [PR120090]

On 5/21/25 4:29 PM, Andrew Pinski wrote: On Wed, May 21, 2025 at 3:21 PM Jeff Law wrote: On 5/5/25 3:27 PM, Andrew Pinski wrote: The problem here is simplify-rtx.cc expects gen_lowpart_no_emit to return NULL on failure but combine's hook was returning CLOBBER. After r1

Re: [PATCH] combine: gen_lowpart_no_emit vs CLOBBER [PR120090]

On 5/5/25 3:27 PM, Andrew Pinski wrote: The problem here is simplify-rtx.cc expects gen_lowpart_no_emit to return NULL on failure but combine's hook was returning CLOBBER. After r16-160-ge6f89d78c1a7528e93458278, gcc.target/i386/avx512bw-pr103750-2.c started to fail at -m32 due to this as new

[to-be-committed][RISC-V] Clear high or low bits using shift pairs

So the first special case of clearing bits from Shreya's work. We can clear an arbitrary number of high bits by shifting left by the number of bits to clear, then logically shifting right to put everything in place. Similarly we can clear an arbitrary number of low bits with a right logica

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

On 5/20/25 1:56 PM, Robin Dapp wrote: Maybe I'm missing something there.  Particularly whether or not you can know anything about frm's value after a call has returned. Normally the answer to this kind of question is a hard no. AFAICT the main difference to standard mode switching is that

[to-be-committed][RISC-V] Improve (x << C1) + C2 split code

I wrote this a couple months ago to fix an instruction count regression in 505.mcf on risc-v, but I don't have a trivial little testcase to add to the suite. There were two problems with the pattern. First, the code was generating a shift followed by an add after reload. Naturally combine doe

Re: [PATCH][RISC-V][PR target/70557] Improve storing 0 to memory on rv32

On 5/21/25 12:20 PM, Shreya Munnangi wrote: Patch is originally from Siarhei Volkau >. RISC-V has a zero register (x0) which we can use to store zero into memory without loading the constant into a distinct register. Adjust the constraints of the 32-bit movdi_32bit

Re: [PATCH V4] RISC-V: Prevent speculative vsetvl insn scheduling

On 5/20/25 4:05 PM, Edwin Lu wrote: The instruction scheduler appears to be speculatively hoisting vsetvl insns outside of their basic block without checking for data dependencies. This resulted in a situation where the following occurs vsetvli a5,a1,e32,m1,tu,ma vle32.v v2,

Re: [PATCH V4] RISC-V: Prevent speculative vsetvl insn scheduling

On 5/20/25 4:05 PM, Edwin Lu wrote: The instruction scheduler appears to be speculatively hoisting vsetvl insns outside of their basic block without checking for data dependencies. This resulted in a situation where the following occurs vsetvli a5,a1,e32,m1,tu,ma vle32.v v2,

Re: [PATCH 2/2] RISC-V:Add testcases for signed .SAT_ADD IMM form 1 with IMM = -1.

On 5/20/25 8:39 PM, Li, Pan2 wrote: Thanks Jeff. So for the tests, why are we forcing matching of the assembly code for the entire function? That must makes for a fragile test as we may change various aspects of code generation over time. If the point of the patch is to detect SAT_ADD in

[to-be-committed][RISC-V][PR target/120368] Fix 32bit shift on rv64

So a followup to last week's bugfix. In last week's change we we stopped using define_insn_and_split to rewrite instructions. That change was done to avoid dropping a masking instruction out of the RTL. As a result the pattern(s) were changed into simple define_insns, which is good. One of

Re: [PATCH 3/3] genemit: Use a byte encoding to generate insns

On 5/21/25 5:06 AM, Richard Sandiford wrote: Jeff Law writes: Given you know the RTL gen* related thingies better than anyone, I'd say go forward and if there's any fallout, we can certainly cope with it. Thanks. I've now pushed the series and the earlier genemit t

[to-be-committed][RISC-V] Infrastructure of synthesizing logical AND with constant

So this is the next step on the path to mvconst_internal removal and is work from Shreya and myself. This puts in the infrastructure to allow us to synthesize logical AND much like we're doing with logical IOR/XOR. Unlike IOR/XOR, AND has many more special cases that can be profitable. For e

Re: [PATCH] match: Remove valueize_condition argument from gimple_extra template

On 5/18/25 10:38 AM, Andrew Pinski wrote: After r15-4791-gb60031e8f9f8fe, the valueize_condition argument becomes unused. I didn't notice that as there was -Wno-unused option being added while compiling gimple-match-exports.cc. This removes that too as there are no unused warnings. gcc/Change

Re: [PATCH 3/3] genemit: Use a byte encoding to generate insns

On 5/18/25 2:41 PM, Richard Sandiford wrote: Target [A] [B] [C] native aarch64 0.5627 0.9585 0.5677 native x86_64 0.5925 0.9467 0.6377 aarch64-x-riscv64 0. 0.9066 0.2762 Nice. So how large

Re: [PATCH v2] driver: Fix multilib_os_dir and multiarch_dir for those target use TARGET_COMPUTE_MULTILIB

On 5/19/25 12:48 AM, Kito Cheng wrote: Hi Jin: Thanks for heads up:) Hi Jeff: I've rebased that on the trunk and everything seems right, do you think it's OK for the trunk? Yea, let's get it on the trunk and get it some soak time. We can then look at backporting it to gcc-15's release br

Re: [PATCH 2/2] RISC-V: Add testcases for signed vector SAT_ADD IMM form 1

On 5/19/25 2:42 AM, Li Xu wrote: From: xuli This patch adds testcase for form1, as shown below: void __attribute__((noinline)) \ vec_sat_s_add_imm_##T##_fmt_1##_##INDEX (T *out, T *op_1, unsigned limit) \ {

Re: [PATCH 2/2] RISC-V:Add testcases for signed .SAT_ADD IMM form 1 with IMM = -1.

On 5/19/25 2:41 AM, Li Xu wrote: From: xuli This patch adds testcase for form1, as shown below: T __attribute__((noinline)) \ sat_s_add_imm_##T##_fmt_1##_##INDEX (T x) \ {\ T sum = (UT)x + (UT)IMM;

Re: [PATCH v2 1/2] The following changes enable P8700 processor for RISCV and P8700 is a high-performance processor from MIPS by extending RISCV with custom instructions.

On 5/19/25 1:02 AM, Umesh Kalappa wrote: --- gcc/config/riscv/mips-p8700.md | 139 +++ gcc/config/riscv/riscv-cores.def | 5 ++ gcc/config/riscv/riscv-opts.h| 3 +- gcc/config/riscv/riscv.cc| 22 + gcc/config/riscv/riscv.md| 3

Re: [PATCH v2 2/2] MIPS p8700 doesn't have vector extension and added the dummies reservation for the same.

On 5/19/25 1:03 AM, Umesh Kalappa wrote: --- gcc/config/riscv/mips-p8700.md | 28 1 file changed, 28 insertions(+) I've pushed this to the trunk as well. Thanks, jeff

[committed][RISC-V][PR target/120333] Remove bogus bext pattern

execution test. Given it's a partial reversion and has passed in my tester, I'm going to go ahead and push it to the trunk rather than waiting for upstream CI. Jeff commit 38fa6c0455ec14f2f42310a817b90765ad894aa4 Author: Jeff Law Date: Mon May 19 16:55:15 2025 -0600 [committed]

Re: [to-be-committed][RISC-V] Avoid setting output object more than once in IOR/XOR synthesis

On 5/18/25 8:53 AM, Mark Wielaard wrote: Should output here be initialized to NULL_RTX? Yea, plus an assert to verify it's sensible after the two blobs of code that emit the [x]ori + bclr/binv sequences. I've pushed a fix to the trunk. jeff

[committed][RISC-V] Fix false positive from Wuninitialized

So this initializes OUTPUT and verifies it's got a reasonable value before using it for the final copy into operands[0]. Bootstrapped on the BPI (regression testing still has ~12hrs to go). Pushing to the trunk. Jeff commit cbc258cd318756db8b5f0e4055dd8f1c1d618d22 Author: Jeff Law Date: M

Re: [PATCH 6/9] genemit: Consistently use operand arrays in gen_* functions

On 5/19/25 3:16 AM, Richard Sandiford wrote: Richard Sandiford writes: Jeff Law writes: So two questions. Is there any meanginful performance impact expected here using the array form rather than locals? And does this impact how folks write their C/C++ fragments in the expanders and

Re: [PATCH 6/9] genemit: Consistently use operand arrays in gen_* functions

On 5/18/25 2:24 PM, Richard Sandiford wrote: gcc/ * genemit.cc (gen_rtx_scratch, gen_exp): Use operands[%d] rather than operand%d. (start_gen_insn): Store the incoming arguments to an operands array. (gen_expand, gen_split): Remove copies into and out of the o

Re: [PATCH 1/9] nds32: Avoid accessing beyond the operands[] array

On 5/18/25 2:19 PM, Richard Sandiford wrote: Jeff Law writes: On 5/16/25 11:32 AM, Jeff Law wrote: On 5/16/25 11:21 AM, Richard Sandiford wrote: This pattern used operands[2] to hold the shift amount, even though the pattern doesn't have an operand 2 (not even as a match_dup).

Re: [to-be-committed][RISC-V] Avoid setting output object more than once in IOR/XOR synthesis

On 5/18/25 8:53 AM, Mark Wielaard wrote: Hi Jeff, On Thu, May 15, 2025 at 10:11:19PM -0600, Jeff Law wrote: This has been tested in my tester and is currently bootstrapping on my BPI. Waiting on data from the pre-commit tester before moving forward... It looks like the Sourceware p550

[to-be-committed][RISC-V] Avoid multiple assignments to output object

This is the next batch of changes to reduce multiple assignments to an output object. This time I'm focused on splitters in bitmanip.md. This doesn't convert every case. For example there is one case that is very clearly dependent on eliminating mvconst_internal and adjustment of a splitter

Re: [PATCH 1/9] nds32: Avoid accessing beyond the operands[] array

On 5/16/25 11:32 AM, Jeff Law wrote: On 5/16/25 11:21 AM, Richard Sandiford wrote: This pattern used operands[2] to hold the shift amount, even though the pattern doesn't have an operand 2 (not even as a match_dup). This caused a build failure with -Werror:    array subscript 2 is

Re: [PATCH] ltmain.in: don't suppress output for PIC compilations

On 5/9/25 11:21 AM, Sam James wrote: Sam James writes: When working on xz, I set `-Werror=suggest-attribute=returns_nonnull`, and the build failed (as I expected it to), but with no visible error from the compiler. There's a mysterious '>/dev/null 2>&1' on the second line where liblzma_la-c

Re: [PATCH] libgcc SH: fix alignment for relaxation

On 5/10/25 11:12 AM, Quentin Boswank wrote: From 6462f1e6a2565c5d4756036d9bc2f39dce9bd768 Mon Sep 17 00:00:00 2001 From: QBos07 Date: Sat, 10 May 2025 16:56:28 + Subject: [PATCH] libgcc SH: fix alignment for relaxation when relaxation is enabled we can not infer the alignment from the p

Re: [PATCH v1 0/1]RISC-V :The following changes enable P8700 MIPS processor for RISC-V.

On 5/12/25 5:20 AM, Umesh Kalappa wrote: --- gcc/config/riscv/mips-p8700.md | 139 +++ gcc/config/riscv/riscv-cores.def | 5 ++ gcc/config/riscv/riscv-opts.h| 3 +- gcc/config/riscv/riscv.cc| 22 + gcc/config/riscv/riscv.md| 3

Re: [PATCH 2/6] RISC-V: frm/mode-switch: remove TARGET_MODE_CONFLUENCE

On 5/14/25 12:06 PM, Vineet Gupta wrote: On 5/13/25 10:07, Vineet Gupta wrote: On 5/10/25 07:20, Jeff Law wrote: On 5/9/25 2:27 PM, Vineet Gupta wrote: This is effectively reverting e5d1f538bb7d "(RISC-V: Allow different dynamic floating point mode to be merged)" while ret

Re: [PATCH 0/6] RISC-V: frm state-machine improvements

On 5/10/25 9:46 PM, Vineet Gupta wrote: Frankly I'm surprised we need FRM adjustments as much as we do, though presumably there's some builtin or somesuch that we need to twiddle FRM to implement and as a result if the builtin ever gets used it leads to FRM games. But it still seems high.

Re: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins

On 5/14/25 2:22 PM, Joseph Myers wrote: On Wed, 14 May 2025, Yuao Ma wrote: Hi Joseph, I have updated the patch based on your review comments. I added the newly introduced builtin to extend.texi and mentioned the PR in the commit message. Could you please take another look when you have a m

Re: [PATCH] RISC-V: Add new operand constraint: cR

On 5/14/25 9:20 PM, Kito Cheng wrote: This commit introduces a new operand constraint `cR` for the RISC-V architecture, which allows the use of an even-odd RVC general purpose register (x8-x15) in inline asm. Ref: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/102 gcc/ChangeLog:

Re: [PATCH] RISC-V: Support Zilsd code gen

On 5/14/25 9:14 PM, Kito Cheng wrote: This commit adds the code gen support for Zilsd, which is a newly added extension for RISC-V. The Zilsd extension allows for loading and storing 64-bit values using even-odd register pairs. We only try to do miminal code gen support for that, which means

[to-be-committed][RISC-V] Fix ICE due to bogus use of gen_rtvec

Found this while setting up the risc-v coordination branch off of gcc-15. Not sure why I didn't use rtvec_alloc directly here since we're going to initialize the whole vector ourselves. Using gen_rtvec was just wrong as it's walking down a non-existent varargs list. Under the "right" circums

Re: [PATCH 2/3] genemit: Avoid using gen_exp in output_add_clobbers

On 5/16/25 11:32 AM, Richard Sandiford wrote: output_add_clobbers emits code to add: (clobber (scratch:M)) and/or: (clobber (reg:M R)) expressions to the end of a PARALLEL. At the moment, it does this using the general gen_exp function. That makes sense with the code in its current

Re: [PATCH 1/3] genemit: Remove support for string operands

On 5/16/25 11:32 AM, Richard Sandiford wrote: gen_exp currently supports the 's' (string) operand type. It would certainly be possible to make the upcoming bytecode patch support that too. However, the rtx codes that have string operands should be very rarely used in hard-coded define_insn/e

Re: [PATCH 8/9] genemit: Always track multiple uses of operands

On 5/16/25 11:22 AM, Richard Sandiford wrote: gen_exp has code to detect when the same operand is used multiple times. It ensures that second and subsequent uses call copy_rtx, to enforce correct unsharing. However, for historical reasons that aren't clear to me, this was skipped for a defin

Re: [PATCH 6/9] genemit: Consistently use operand arrays in gen_* functions

On 5/16/25 11:21 AM, Richard Sandiford wrote: One slightly awkward part about emitting the generator function bodies is that: * define_insn and define_expand routines have a separate argument for each operand, named "operand0" upwards. * define_split and define_peephole2 routines take a p

Re: [PATCH 9/9] genemit: Remove purported handling of location_ts

On 5/16/25 11:22 AM, Richard Sandiford wrote: gen_exp had code to handle the 'L' operand format. But this format is specifically for location_ts, which are only used in RTX_INSNs. Those should never occur in this context, where the input is always an md file rather than an __RTL function. An

Re: [PATCH 7/9] genemit: Add a generator struct

On 5/16/25 11:22 AM, Richard Sandiford wrote: gen_exp now has quite a few arguments that need to be passed to each recursive call. This patch turns it and related routines into member functions of a new generator class, so that the shared information can be stored in member variables. This a

Re: [PATCH 5/9] genemit: Factor out code common to insns and expands

On 5/16/25 11:21 AM, Richard Sandiford wrote: Mostly to reduce cut-&-paste. gcc/ * genemit.cc (start_gen_insn): New function, split out from... (gen_insn, gen_expand): ...here. OK jeff

Re: [PATCH 4/9] genemit: Add an internal queue

On 5/16/25 11:21 AM, Richard Sandiford wrote: An earlier version of this series wanted to collect information about all the gen_* functions that are going to be generated. The current version no longer does that, but the queue seemed worth keeping anyway, since it gives a more consistent struc

Re: [PATCH 3/9] genemit: Use references rather than pointers

On 5/16/25 11:21 AM, Richard Sandiford wrote: This patch makes genemit.cc pass the md_rtx_info around by constant reference rather than pointer. It's somewhat of a cosmetic change on its own, but it makes later changes less noisy. gcc/ * genemit.cc (gen_exp): Make the info argument a

Re: [PATCH 1/9] nds32: Avoid accessing beyond the operands[] array

On 5/16/25 11:21 AM, Richard Sandiford wrote: This pattern used operands[2] to hold the shift amount, even though the pattern doesn't have an operand 2 (not even as a match_dup). This caused a build failure with -Werror: array subscript 2 is above array bounds of ‘rtx_def* [2]’ gcc/

Re: [PATCH 2/9] xstormy16: Avoid accessing beyond the operands[] array

On 5/16/25 11:21 AM, Richard Sandiford wrote: The negsi2 C++ code writes to operands[2] even though the pattern has no operand 2. gcc/ * config/stormy16/stormy16.md (negsi2): Remove unused assignment. Also obviously OK. jeff

Re: [PATCH] RISC-V: Since the loop increment i++ is unreachable, the loop body will never execute more than once

On 5/16/25 1:32 AM, Jin Ma wrote: Reported-by: huangcunjian gcc/ChangeLog: * config/riscv/riscv.cc (riscv_gpr_save_operation_p): Remove break and fixbug for elt index. Ideally we'd have a testcase for whatever issue motivated this change, but it's pretty clear that the elem

Re: [PATCH v1] RISC-V: Avoid scalar unsigned SAT_ADD test data duplication

On 5/16/25 2:38 AM, pan2...@intel.com wrote: From: Pan Li Some of the previous scalar unsigned SAT_ADD test data are duplicated in different test files. This patch would like to move them into a shared header file, to avoid the test data duplication. The below test suites are passed for th

[to-be-committed][RISC-V] Avoid setting output object more than once in IOR/XOR synthesis

While evaluating Shreya's logical AND synthesis work on spec2017 I ran into a code quality regression where combine was failing to eliminate a redundant sign extension. I had a hunch the problem would be with the multiple sets of the same pseudo register in the AND synthesis path. I was right

Re: [PATCH] RISC-V: Fix the warning of temporary object dangling references.

On 5/15/25 8:35 PM, Kito Cheng wrote: Hm, it really doesn't make too much sense to get that warning, but I can reproduce that when I compile with gcc 13 (and newer)...and seems like a known issue [1][2]... I still hadn't managed to convince myself the code was wrong. It looked more like

Re: [PATCH 1/4] Make end_sequence return the insn sequence

On 5/15/25 11:18 AM, Richard Sandiford wrote: The start_sequence/end_sequence interface was a big improvement over the previous state, but one slightly awkward thing about it is that you have to call get_insns before end_sequence in order to get the insn sequence itself: I can't even remember

Re: [PING][PATCH][GCC15] Alpha: Fix base block alignment calculation regression

On 5/12/25 11:21 AM, Maciej W. Rozycki wrote: On Tue, 25 Feb 2025, Maciej W. Rozycki wrote: Address this issue by recursing into COMPONENT_REF tree nodes until the outermost one has been reached, which is supposed to be a MEM_REF one, accumulating the offset as we go, fixing a commit e0dae4d

Re: [PATCH] RISC-V: Fix uninit riscv_subset_list::m_allow_adding_dup issue

On 5/12/25 8:34 PM, Kito Cheng wrote: We forgot to initialize m_allow_adding_dup in the constructor of riscv_subset_list, then that will be a random value...that will lead to a random behavior of the -march may accpet duplicate extension. gcc/ChangeLog: * common/config/riscv/riscv-co

[to-be-committed][RISC-V][PR target/120223] Don't use bset/binv for XTHEADBS

Thead has the XTHEADBB extension which has a lot of overlap with Zbb. I made the incorrect assumption that XTHEADBS would largely be like Zbs when generalizing Shreya's work. As a result we can't use the operation synthesis code for IOR/XOR because we don't have binv/bset like capabilities.

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

On 5/12/25 4:17 PM, Vineet Gupta wrote: On 5/12/25 14:55, Jeff Law wrote: test_float_point_frm_static: 1: frrma5 <-- 2: fsrmi 2 3: fsrma5 <-- 4: callnormalize_vl 5: frrma5 <-- 6:

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

On 5/10/25 9:55 PM, Vineet Gupta wrote: On 5/10/25 07:17, Jeff Law wrote: On 5/9/25 2:27 PM, Vineet Gupta wrote: This showed up when debugging the testcase for PR119164. RISC-V FRM mode-switching state machine has special handling for transitions to and from a call_insn as FRM needs to

Re: [PATCH v4 1/2] RISC-V: Support RISC-V Profiles 20/22.

On 5/10/25 6:30 AM, Jiawei wrote: This patch introduces support for RISC-V Profiles RV20 and RV22 [1], enabling developers to utilize these profiles through the -march option. [1] https://github.com/riscv/riscv-profiles/releases/tag/v1.0 Version log: Using lowercase letters to present Profil

Re: [PATCH 1/6] emit-rtl: document next_nonnote_nondebug_insn_bb () can breach into next BB

On 5/9/25 2:27 PM, Vineet Gupta wrote: gcc/ChangeLog: * emit-rtl.cc (next_nonnote_nondebug_insn): Update comments. Signed-off-by: Vineet Gupta --- gcc/emit-rtl.cc | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc index 3e2c

  1   2   3   4   5   6   7   8   9   10   >