Re: [PATCH 1/3] Change 'v1' float and int code to fall back to v0

On 2/28/24 15:57, Tom Tromey wrote: "Jeff" == Jeff Law writes: I could not push this because: remote: *** ChangeLog format failed: remote: *** ERR: invalid PR component in subject: "Fix PR libcc1/113977" I guess this script isn't in sync with the components i

Re: [PATCH] Add a late-combine pass [PR106594]

On 1/10/24 06:35, Richard Biener wrote: I think x86 maintainers could opt to disable the pass - so it would be opt-out. It's reasonable to expect them to fix the backend given there's nothing really wrong with the new pass, it just does something that wasn't done before at that point? That's

Re: [PATCH] Add a late-combine pass [PR106594]

On 1/10/24 06:01, Richard Sandiford wrote: So to get an idea for expectations: would it be a requirement that a GCC 15 submission is enabled unconditionally and all known issues in the ports fixed? I don't think we need to fix those latent port issues as a hard requirement. I try to balance

Re: [PATCH] config: delete unused CYG_AC_PATH_LIBERTY macro

On 1/9/24 19:04, Mike Frysinger wrote: Nothing uses this, so delete it to avoid confusion. config/ChangeLog: * acinclude.m4 (CYG_AC_PATH_LIBERTY): Delete. OK jeff

[committed] Fix MIPS bootstrap

pare against, so no regression test data. Pushed to the trunk, Jeff commit e927cfa842c16bea902500e69ab4eca2ef15af4e Author: Jeff Law Date: Sun Jan 14 07:53:49 2024 -0700 [committed] Fix MIPS bootstrap mips bootstraps have been broken for a while. They've been triggering an error about mutually ex

Re: [patch, avr, ping #3] PR target/112944: Support .rodata in RAM for AVR64* and AVR128* devices

On 1/14/24 06:05, Georg-Johann Lay wrote: Ping #3 RFA: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640140.html Ping #1 https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640981.html Ping #2 https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641912.html This is a patch th

Re: [PATCH] testsuite: Reduce gcc.dg/torture/inline-mem-cpy-1.c by 11 for simulators

On 1/2/24 14:07, Hans-Peter Nilsson wrote: On Tue, 2 Jan 2024, Jeff Law wrote: On 1/1/24 20:22, Hans-Peter Nilsson wrote: Tested mmix-knuth-mmixware (where all torture-variants of gcc.dg/torture/inline-mem-cpy-1.c now pass) and native x86_64-pc-linux-gnu. Also stepped through the test for

Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c

On 1/12/24 06:59, Maciej W. Rozycki wrote: On Fri, 12 Jan 2024, Andrew Pinski wrote: Verify that if-conversion succeeded through noce_try_store_flag_mask, as per PR rtl-optimization/105314, tightening the test case and making it explicit. gcc/testsuite/ * gcc.target/riscv/

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

On 1/9/24 17:58, Kito Cheng wrote: Oops, I should leave more context here: Actually we discussed that years ago, and most people agree with that, but I guess we are just missing that, and also the ISA string isn't so terribly long yet at that moment, however...the number of extensions are

Re: [PATCH v3 1/8] sched-deps.cc (find_modifiable_mems): Avoid exponential behavior

On 1/15/24 05:56, Maxim Kuvyrkov wrote: Hi Vladimir, Hi Jeff, Richard and Alexander have reviewed this patch and [I assume] have no further comments.  OK to merge? I think the question is whether or not we're too late. I know that Richard S has held off on his late-combine pass and I'm hol

Re: [RFA] [V3] new pass for sign/zero extension elimination

On 1/3/24 05:07, Richard Sandiford wrote: Jeff Law writes: I know we're deep into stage3 and about to transition to stage4. So if the consensus is for this to wait, I'll understand This it the V3 of the ext-dce patch based on Joern's work from last year. Changes since

Re: [PATCH] Mark ASM_OUTPUT_FUNCTION_LABEL ()'s DECL argument as used

On 1/15/24 02:22, Ilya Leoshkevich wrote: Compile tested for the ia64-elf target; bootstrap and regtest running on x86_64-redhat-linux. Ok for trunk when successful? ia64-elf build fails with the following warning: [all 2024-01-12 16:32:34] ../../gcc/gcc/config/ia64/ia64.cc:3889:59

Re: [PATCH, expand] Add const0 move checking for CLEAR_BY_PIECES optabs

On 1/15/24 19:04, HAO CHEN GUI wrote: Hi, This patch adds const0 move checking for CLEAR_BY_PIECES. The original vec_duplicate handles duplicates of non-constant inputs. But 0 is a constant. So even a platform doesn't support vec_duplicate, it could still do clear by pieces if it supports c

Re: [PATCH] match: Do not select to branchless expression when target has movcc pattern [PR113095]

On 1/17/24 05:14, Richard Biener wrote: On Wed, 17 Jan 2024, Monk Chiang wrote: This allows the backend to generate movcc instructions, if target machine has movcc pattern. branchless-cond.c needs to be updated since some target machines have conditional move instructions, and the experssio

Re: [PATCH 1/4] rtl-ssa: Run finalize_new_accesses forwards [PR113070]

On 1/13/24 08:43, Alex Coplan wrote: The next patch in this series exposes an interface for creating new uses in RTL-SSA. The intent is that new user-created uses can consume new user-created defs in the same change group. This is so that we can correctly update uses of memory when inserting

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

On 1/17/24 20:53, Greg McGary wrote: On Tue, Jan 16, 2024 at 11:44 PM Richard Biener mailto:richard.guent...@gmail.com>> wrote: > On Tue, Jan 16, 2024 at 11:20 PM Greg McGary > wrote: > > > > The sign bit of a sign-extending load cannot be known until runtime,

Re: [middle-end PATCH] Prefer PLUS over IOR in RTL expansion of multi-word shifts/rotates.

On 1/19/24 09:05, Georg-Johann Lay wrote: Am 18.01.24 um 20:54 schrieb Roger Sayle: This patch tweaks RTL expansion of multi-word shifts and rotates to use PLUS rather than IOR for disjunctive operations.  During expansion of these operations, the middle-end creates RTL like (X<>C2) where

Re: [PATCH] RISC-V: Add split pattern to generate SFB instructions. [PR113095]

On 1/19/24 00:09, Kito Cheng wrote: Thanks! generally LGTM, but I would wait one more week to see any other comments :)Just a note. 113095 isn't marked as a regression, but it most definitely is a regression. So this meets the stage4 criteria. On Fri, Jan 19, 2024 at 3:05 PM Monk Chian

Re: [PATCH v5] RISC-V: Support XTheadVector extension

On 1/18/24 07:43, Christoph Müllner wrote: On Fri, Jan 12, 2024 at 4:18 AM Jun Sha (Joshua) wrote: This patch series presents gcc implementation of the XTheadVector extension [1]. [1] https://github.com/T-head-Semi/thead-extension-spec/ For some vector patterns that cannot be avoided, we

Re: [PATCH] Avoid ICE in single-bit logical RMWs on m68k-uclinux [PR108640]

On 1/18/24 09:39, Mikael Pettersson wrote: When generating RMW logical operations on m68k, the backend recognizes single-bit operations and rewrites them as bit instructions on operands adjusted to address the intended byte. When offsetting the addresses the backend keeps the modes as SImode,

Re: [PATCH] Avoid ICE on m68k -fzero-call-used-regs -fpic [PR110934]

On 1/17/24 10:03, Mikael Pettersson wrote: PR110934 is a problem on m68k where -fzero-call-used-regs -fpic ICEs when clearing an FP register. The generic code generates an XFmode move of zero to that register, which becomes an XFmode load from initialized data, which due to -fpic uses a non-c

Re: [Committed] RISC-V: Suppress warning

On 1/19/24 17:27, Juzhe-Zhong wrote: ../../gcc/config/riscv/riscv.cc: In function 'void riscv_init_cumulative_args(CUMULATIVE_ARGS*, tree, rtx, tree, int)': ../../gcc/config/riscv/riscv.cc:4879:34: error: unused parameter 'fndecl' [-Werror=unused-parameter] 4879 |

[committed] [NFC] Fix riscv_init_cumulative_args for unused arguments

The signature was still using ATTRIBUTE_UNUSED and actually marked one of the used arguments with ATTRIBUTE_UNUSED. This patch drops the decorations and instead remove the name of arguments which are actually unused which is the preferred way to handle this now when we can. Bootstrapped.

Re: [Committed] RISC-V: Suppress warning

On 1/19/24 18:18, 钟居哲 wrote: OK. I saw the other arguments there:                             tree fntype ATTRIBUTE_UNUSED,                             rtx libname ATTRIBUTE_UNUSED, So I leverage these and add ATTRIBUTE_UNUSED to 'fndecl' Maybe it's better remove all arguments for riscv_i

Re: [PATCH] sra: Disqualify bases of operands of asm gotos

On 1/17/24 11:21, Martin Jambor wrote: Hi, PR 110422 shows that SRA can ICE assuming there is a single edge outgoing from a block terminated with an asm goto. We need that for BB-terminating statements so that any adjustments they make to the aggregates can be copied over to their replacemen

Re: [PATCH] Avoid ICE with m68k-elf -malign-int and libcalls

On 1/16/24 09:55, Mikael Pettersson wrote: On Thu, 4 Jan 2024 14:39:23 -0700, Jeff Law wrote: On 1/4/24 02:23, Mikael Pettersson wrote: emit_library_call_value_1 calls emit_push_insn with NULL_TREE for TYPE. Sometimes emit_push_insn needs to assign a temp with that TYPE, which causes a

Re: [PATCH v2 1/1] RISC-V: Add support for XCVbitmanip extension in CV32E40P

On 1/16/24 09:25, Mary Bennett wrote: Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md Contributors: Mary Bennett Nandni Jamnadas Pietra Ferreira Charlie Keaney Jessica Mills Craig Blackmore Simon Cook Jeremy Bennett Hel

Re: [PATCH v3 2/2] RISC-V: Fix XCValu test

On 1/16/24 10:13, Mary Bennett wrote: gcc/testsuite/ChangeLog: * gcc.target/riscv/cv-alu-fail-compile.c: Change warning to error. AFAICT this is independent of the other patches and fixes a clear testsuite issue. I've pushed it to the trunk. Thanks, Jeff

[committed] Adjust expectations for pr59533-1.c

st as all those are either a wash or a The fwprop change does cause some code regressions on the same test. I'll file a distinct but for that issue. Pushed to the trunk, Jeffcommit 7e16f819ff413c48702f9087b62eaac39a060a14 Author: Jeff Law Date: Sun Jan 21 19:12:21 2024 -0700 [committ

Re: [PATCH 1/2] rtl-optimization/113255 - base_alias_check vs. pointer difference

On 1/15/24 06:34, Richard Biener wrote: When the x86 backend generates code for cpymem with the rep_8byte strathegy for the 8 byte aligned main rep movq it needs to compute an adjusted pointer to the source after doing a prologue aligning the destination. It computes that via src_ptr + (d

Re: [PATCH 1/2] rtl-optimization/113255 - base_alias_check vs. pointer difference

On 1/15/24 06:34, Richard Biener wrote: When the x86 backend generates code for cpymem with the rep_8byte strathegy for the 8 byte aligned main rep movq it needs to compute an adjusted pointer to the source after doing a prologue aligning the destination. It computes that via src_ptr + (d

Re: [middle-end PATCH] Prefer PLUS over IOR in RTL expansion of multi-word shifts/rotates.

On 1/22/24 00:45, Richard Biener wrote: On Fri, Jan 19, 2024 at 5:06 PM Georg-Johann Lay wrote: Am 18.01.24 um 20:54 schrieb Roger Sayle: This patch tweaks RTL expansion of multi-word shifts and rotates to use PLUS rather than IOR for disjunctive operations. During expansion of these o

Re: [PATCH 2/2] find_base_value part

On 1/15/24 06:34, Richard Biener wrote: The following adjusts find_base_value similar as to what find_base_term was adjusted for PR113255. * alias.cc (known_base_value_p): Remove. (find_base_value): Remove PLUS/MINUS handling when both operands are not CONST_INT_P. OK

Re: [PATCH v2] RISC-V: Add split pattern to generate SFB instructions. [PR113095]

On 1/21/24 23:12, Monk Chiang wrote: Since the match.pd transforms (zero_one == 0) ? y : z y, into ((typeof(y))zero_one * z) y. Add splitters to recongize this expression to generate SFB instructions. gcc/ChangeLog: PR target/113095 * config/riscv/sfb.md: New splitters to re

Re: [PATCH 1/2] RISC-V/testsuite: Add RTL pr105314.c testcase variants

On 1/24/24 04:16, Maciej W. Rozycki wrote: Add a pair of RTL tests, for RV64 and RV32 respectively, corresponding to the existing pr105314.c test. They have been produced from RTL code as at the entry of the "ce1" pass for pr105314.c compiled at -O3. gcc/testsuite/ * gcc.targ

Re: [PATCH 2/2] RISC-V/testsuite: Add RTL cset-sext.c testcase variants

On 1/24/24 04:16, Maciej W. Rozycki wrote: Add RTL tests, for RV64 and RV32 where appropriate, corresponding to the existing cset-sext.c tests. They have been produced from RTL code as at the entry of the "ce1" pass for the respective cset-sext.c tests built at -O3. gcc/testsuite/

Re: [PATCH v3] RISC-V: Add split pattern to generate SFB instructions. [PR113095]

On 1/24/24 05:54, Monk Chiang wrote: Since the match.pd transforms (zero_one == 0) ? y : z y, into ((typeof(y))zero_one * z) y. Add splitters to recongize this expression to generate SFB instructions. gcc/ChangeLog: PR target/113095 * config/riscv/sfb.md: New splitters to re

Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c

On 1/24/24 04:26, Maciej W. Rozycki wrote: On Tue, 16 Jan 2024, Maciej W. Rozycki wrote: I don't have a strong opinion on this. I certainly see Andrew's point, but it's also the case that if some work earlier in the RTL or gimple pipeline comes along and compromises the test, then we'd see

Re: [PATCH] testsuite: require libc sym for -shared

On 1/23/24 00:15, Alexandre Oliva wrote: Targets whose binutils support -shared, but that don't have a shared libc, and that can't add PDC (non-PIC) to shared libraries, may succeed at the effective target test for -shared, because it brings nothing from libc, but tests that rely on -shared a

Re: [PATCH] testsuite: no dfp run without dfprt

On 1/23/24 00:13, Alexandre Oliva wrote: newlib-src/libc/include/sys/fenv.h doesn't define the FE_* macros that libgcc expects to enable decimal float support. Only after newlib is configured and built does an overriding header that defines those macros become available in objdir//newlib/tar

Re: [PATCH] testsuite/vect: Add target checks to refined patterns [PR113558]

On 1/24/24 07:40, Robin Dapp wrote: Hi, on Solaris/SPARC several vector tests appeared to be regressing. They were never vectorized but the checks before r14-3612-ge40edf64995769 would match regardless if a loop was actually vectorized or not. The refined checks only match a successful vecto

Re: [PATCH] RISC-V: Don't make Ztso imply A

On 1/24/24 17:07, Patrick O'Neill wrote: On 12/16/23 10:58, Jeff Law wrote: On 12/15/23 17:14, Andrew Waterman wrote: On Fri, Dec 15, 2023 at 1:38 PM Jeff Law wrote: On 12/12/23 20:54, Palmer Dabbelt wrote: I can't actually find anything in the ISA manual that makes Zt

Re: [middle-end PATCH take #2] Only call targetm.truly_noop_truncation for truncations.

On 12/31/23 09:23, Roger Sayle wrote: Very many thanks (and a Happy New Year) to the pre-commit patch testing folks at linaro.org. Their testing has revealed that although my patch is clean on x86_64, it triggers some problems on aarch64 and arm. The issue (with the previous version of my

[committed] Minor testsuite fallout from c99 changes

The alpha port recently failed its weekly test due to a lack of a prototype for the syscall() routine. Fixed thusly and pushed to the trunk. Jeff commit acfd33620af3519b84baecedb0eb6618c2f599a6 Author: Jeff Law Date: Wed Dec 13 17:24:39 2023 -0700 [committed] Minor testsuite fallout

Re: [PATCH] RISC-V: fix scalar crypto pattern

On 12/13/23 02:03, Christoph Müllner wrote: On Wed, Dec 13, 2023 at 9:22 AM Liao Shihua wrote: In Scalar Crypto Built-In functions, some require immediate parameters, But register_operand are incorrectly used in the pattern. E.g.: __builtin_riscv_aes64ks1i(rs1,1) Before: li

[committed] Fix m68k testcase for c99

679adb2396a911b5999591f7a4f27a88064e91ff Author: Jeff Law Date: Thu Dec 14 06:31:49 2023 -0700 [committed] Fix m68k testcase for c99 More fallout from the c99 conversion. The m68k specific test pr63347.c calls exit and abort without a prototype in scope. This patch turns them into

Re: [PATCH] RISC-V: fix scalar crypto pattern

On 12/14/23 02:48, Christoph Müllner wrote: On Thu, Dec 14, 2023 at 1:40 AM Jeff Law wrote: On 12/13/23 02:03, Christoph Müllner wrote: On Wed, Dec 13, 2023 at 9:22 AM Liao Shihua wrote: In Scalar Crypto Built-In functions, some require immediate parameters, But register_operand are

Re: [PATCH] RISC-V: fix scalar crypto pattern

On 12/14/23 02:48, Christoph Müllner wrote: On Thu, Dec 14, 2023 at 1:40 AM Jeff Law wrote: On 12/13/23 02:03, Christoph Müllner wrote: On Wed, Dec 13, 2023 at 9:22 AM Liao Shihua wrote: In Scalar Crypto Built-In functions, some require immediate parameters, But register_operand are

Re: [PATCH] RISC-V: fix scalar crypto pattern

On 12/14/23 04:12, Liao Shihua wrote: Sorry, I was not aware of this patch. Since Jeff's patch was here first and also includes more tests, I propose to move forward with his patch (but I'm not a maintainer!). Therefore, I've reviewed Jeff's patch and replied to his email. FWIW: Jeff's patch

Re: [PR target/110201] Fix operand types for various scalar crypto insns

On 12/14/23 02:46, Christoph Müllner wrote: On Tue, Jun 20, 2023 at 12:34 AM Jeff Law via Gcc-patches wrote: A handful of the scalar crypto instructions are supposed to take a constant integer argument 0..3 inclusive. A suitable constraint was created and used for this purpose (D03), but

Re: [PATCH] RISC-V: Add Zvfbfmin extension to the -march= option

On 12/12/23 20:24, Xiao Zeng wrote: This patch would like to add new sub extension (aka Zvfbfmin) to the -march= option. It introduces a new data type BF16. Depending on different usage scenarios, the Zvfbfmin extension may depend on 'V' or 'Zve32f'. This patch only implements dependencies in

Re: [PR target/110201] Fix operand types for various scalar crypto insns

On 12/14/23 17:14, Christoph Müllner wrote: On Fri, Dec 15, 2023 at 12:36 AM Jeff Law wrote: On 12/14/23 02:46, Christoph Müllner wrote: On Tue, Jun 20, 2023 at 12:34 AM Jeff Law via Gcc-patches wrote: A handful of the scalar crypto instructions are supposed to take a constant

Re: [PATCH] RISC-V: Don't make Ztso imply A

On 12/12/23 20:54, Palmer Dabbelt wrote: I can't actually find anything in the ISA manual that makes Ztso imply A. In theory the memory ordering is just a different thing that the set of availiable instructions (ie, Ztso without A would still imply TSO for loads and stores). It also seems li

Re: [PATCH] RISC-V: Add -fno-vect-cost-model to pr112773 testcase

On 12/14/23 14:32, Patrick O'Neill wrote: The testcase for pr112773 started passing after r14-6472-g8501edba91e which was before the actual fix. This patch adds -fno-vect-cost-model which prevents the testcase from passing due to the vls change. gcc/testsuite/ChangeLog: * gcc.target/

Re: [PATCH v4 1/3] RISC-V: Add support for XCVelw extension in CV32E40P

On 12/12/23 12:32, Mary Bennett wrote: Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md Contributors: Mary Bennett Nandni Jamnadas Pietra Ferreira Charlie Keaney Jessica Mills Craig Blackmore Simon Cook Jeremy Bennett He

Re: [PATCH v4 2/3] RISC-V: Update XCValu constraints to match other vendors

On 12/12/23 12:32, Mary Bennett wrote: gcc/ChangeLog: * config/riscv/constraints.md: CVP2 -> CV_alu_pow2. * config/riscv/corev.md: Likewise. --- Kito ack'd the V3 patch, so I went ahead and pushed this to the trunk. jeff

Re: [PATCH v4 3/3] RISC-V: Add support for XCVbi extension in CV32E40P

On 12/12/23 12:32, Mary Bennett wrote: Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md Contributors: Mary Bennett Nandni Jamnadas Pietra Ferreira Charlie Keaney Jessica Mills Craig Blackmore Simon Cook Jeremy Bennett He

Re: [PATCH] RISC-V: Don't make Ztso imply A

On 12/15/23 17:14, Andrew Waterman wrote: On Fri, Dec 15, 2023 at 1:38 PM Jeff Law wrote: On 12/12/23 20:54, Palmer Dabbelt wrote: I can't actually find anything in the ISA manual that makes Ztso imply A. In theory the memory ordering is just a different thing that the s

RFC -- targets with unsigned bifields

So mcore-elf is the slowest target to test with a simulator. Not because it's simulator is particularly bad, but because some tests timeout as they've gotten into infinite loops. This causes the mcore-elf port to take about 2X longer than most other gdbsim ports. I tracked this down to th

Re: [RFC][V2] RISC-V: Support -mcmodel=large.

On 11/10/23 02:10, KuanLin Chen wrote: Sorry. It missed a semicolon in the previos patch. Please find the new one in the attachment. Thanks. Thanks. I was going to do some final testing with the plan to integrate this patch today, but I think there's a piece missing. Specifically I think i

Re: [PATCH] middle-end: Call negate_rtx instead of simplify_gen_unary expanding rotate shift [PR113033]

On 12/18/23 06:42, Xi Ruoyao wrote: With simplify_gen_unary we end up with a not fully expanded RTX like (set (reg:SI 90) (and:SI (neg:SI (reg:SI 80)) (const_int 63))) Then it will cause an ICE with unrecognizable insn. gcc/ChangeLog: PR middle-end/113033 * expmed.cc (

Re: RFC -- targets with unsigned bifields

On 12/18/23 11:32, Joseph Myers wrote: On Sat, 16 Dec 2023, Jeff Law wrote: I tracked this down to the port unconditionally adding -funsigned-bitfields to CC1_SPEC. According to the comment it's how the ABI is defined for the mcore targets. We explicitly document (under Non-bu

Re: [pushed][PR112918][LRA]: Fixing IRA ICE on m68k

On 12/18/23 15:16, Vladimir Makarov wrote: The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918 The patch was successfully bootstrapped and tested on x86-64, aarch64, and ppc64. The patch affects a sensitive part of LRA.  So I will monitor that the commit does no

Re: [pushed][PR112918][LRA]: Fixing IRA ICE on m68k

On 12/18/23 17:05, Jeff Law wrote: On 12/18/23 15:16, Vladimir Makarov wrote: The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918 The patch was successfully bootstrapped and tested on x86-64, aarch64, and ppc64. The patch affects a sensitive part of LRA.  So

Re: [PATCH FYI] -finline-stringops: copy timeout factor from memcmp-1.c test

On 12/19/23 19:32, Alexandre Oliva wrote: Hi, Jeff, On Dec 18, 2023, Jeff Law wrote: These are timing sporadically on the embedded platforms. Given they include a test that has a timeout factor, it seems to me you should duplicate the timeout factor in the new tests. Remember when you

Re: [PATCH v1] RISC-V: Bugfix for the const vector in single steps

On 12/19/23 19:50, juzhe.zh...@rivai.ai wrote: +   if (known_eq (ele_0 - 0, ele_n - v.npatterns ())) -> for (i = 0; i < v.npatterns (); )   check each nelt of npatterns is equal to vid. Pan -- please indicate what testing was performed. The standard is to test with and without the p

[committed] Stop forcing unsigned bitfields on mcore

gging into pr88621 to begin with. Pushed to the trunk. Jeffcommit 6c22779dfb09f9691c2893c5cabfe35187e1b9f6 Author: Jeff Law Date: Tue Dec 19 21:05:25 2023 -0700 [committed] Stop forcing unsigned bitfields on mcore The GCC manual has a whole section on signedness of bitfield

[committed][gcc-wwwdocs] Add blurb about bitfield signedness on mcore

Pushed to the trunk. jeffcommit e56dc0003729ea6f7d26594dae34d218543edb49 Author: Jeff Law Date: Tue Dec 19 21:28:03 2023 -0700 Document that bitfields are signed on mcore now. diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index eb14e09d..11c7ca7e 100644 --- a

Problems with strub tests

So the strub tests in c-c++-common are problematical. They get run twice, once for C, once for C++. Yet the name of the test is the same in both runs. (by the name, I mean the name emitted into the dejagnu summary and log files). Thus if you have a test in there which passes in one contex

Re: [PATCH] untyped calls: enable target switching [PR112334]

On 12/11/23 21:44, Alexandre Oliva wrote: untyped calls: use wrapper class type for implicit plus_one Instead of get and set macros to apply a delta, use a single macro that resorts to a temporary wrapper class to apply it. To be combined (or not) with the previous patch. I'd be OK with

Re: [PATCH] contrib: add git gcc-style alias

On 12/11/23 20:00, Jason Merrill wrote: OK for trunk? -- 8< -- I thought it could be easier to use check_GNU_style.py. With this alias, 'git gcc-style' will take a git revision as argument instead of a file, or check HEAD if no argument is given. contrib/ChangeLog: * gcc-git-custo

Re: [PATCH] tree-object-size: Clean up unknown propagation

On 12/19/23 10:21, Siddhesh Poyarekar wrote: Narrow down scope of the unknowns bitmap so that it is only accessible within the reexamination process. This also removes any role of unknown propagation from object_sizes_set, thus simplifying that code path a bit. gcc/ChangeLog: * tree

Re: [PATCH v2 1/3] RISC-V: movmem for RISCV with V extension

On 12/19/23 02:53, Sergei Lewis wrote: gcc/ChangeLog * config/riscv/riscv.md (movmem): Use riscv_vector::expand_block_move, if and only if we know the entire operation can be performed using one vector load followed by one vector store gcc/testsuite/ChangeLog PR target

Re: [PATCH v2 2/3] RISC-V: setmem for RISCV with V extension

On 12/19/23 02:53, Sergei Lewis wrote: gcc/ChangeLog * config/riscv/riscv-protos.h (riscv_vector::expand_vec_setmem): New function declaration. * config/riscv/riscv-string.cc (riscv_vector::expand_vec_setmem): New function: this generates an inline vectorised memory set,

Re: [PATCH] RISC-V: Fix calculation of max live vregs

On 12/20/23 04:17, juzhe.zh...@rivai.ai wrote: I see. LGTM. Thanks for explanation. I will ask Li Pan commit it for you. The patch from Demin didn't specify if it had been regression tested. All patches must be regression tested and an indication that the test passed and on what target mus

Re: [PATCH v2 2/3] RISC-V: setmem for RISCV with V extension

On 12/20/23 02:48, Sergei Lewis wrote: Hi, This has been tested with the following configurations: rv64gcv_zvl128b rv64gcv_zvl256b rv32imafd_zve32x1p0 rv32gc_zve64f_zvl128b I'll drop the constraints and add the testing info to the cover email in v3. I'll hold off submitting v3 until gcc-15

Re: [PATCH] RISC-V: Fix RISCV_FUSE_ZEXTWS fusion condition

On 12/20/23 01:39, Wang Pengcheng wrote: From: wangpc The condition is RISCV_FUSE_ZEXTH, which is a mistake. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix condition. Thanks! As soon as this patch finishes regression testing I'll push it to the trunk. I'm curiou

Re: [PATCH] compare_tests: distinguish c-c++-common results by tool

On 12/19/23 23:31, Alexandre Oliva wrote: On Dec 20, 2023, Jeff Law wrote: So the strub tests in c-c++-common are problematical. They get run twice, once for C, once for C++. Yet the name of the test is the same in both runs. (by the name, I mean the name emitted into the dejagnu summary

Re: [PATCH] RISC-V: Fix RISCV_FUSE_ZEXTWS fusion condition

On 12/20/23 01:39, Wang Pengcheng wrote: The condition is RISCV_FUSE_ZEXTH, which is a mistake. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix condition. I've pushed this to the trunk. Attached is the actual patch committed which also fixes formatting of that code.

Re: [PATCH] RISC-V: Optimize SELECT_VL codegen when length is known as smaller than VF

On 12/19/23 23:55, Juzhe-Zhong wrote: While trying to fix bugs of PR113097, notice this following situation we generate redundant vsetvli _255 = SELECT_VL (3, POLY_INT_CST [4, 4]); COND_LEN (..., _255) Before this patch: vsetivli a5, 3... ... vadd.vv (use a5) After this patch: ... vadd.vv

Re: [PATCH] RISC-V: Fix bug of VSETVL fusion

On 12/19/23 23:50, Juzhe-Zhong wrote: This patch fixes bugs in the fusion of this following case: li a5,-1 vmv.s.x v0,a5 -> demand any non-zero AVL vsetvli a5, ... Incorrect fusion after VSETVL PASS: li a5,-1 vsetvli a5... vmv.s.x v0, a5 --> a5 is modified as incorrect value. We disallow t

Re: [RFC][V2] RISC-V: Support -mcmodel=large.

On 12/18/23 00:46, KuanLin Chen wrote: Hi Jeff, Sorry for this missing. I've removed riscv_asm_output_pool_epilogue because the pool beginning is always aligned from FUNCTION_BOUNDARY. Please find attached. Thank you. Thanks. I regression tested this on rv64gc without any issues and fixed

Re: [RFC][V2] RISC-V: Support -mcmodel=large.

On 12/20/23 11:05, Palmer Dabbelt wrote: On Wed, 20 Dec 2023 09:55:48 PST (-0800), jeffreya...@gmail.com wrote: On 12/18/23 00:46, KuanLin Chen wrote: Hi Jeff, Sorry for this missing. I've removed riscv_asm_output_pool_epilogue because the pool beginning is always aligned from FUNCTION_BO

Re: [PATCH] RISC-V: Document -mcmodel=large

On 12/20/23 11:08, Palmer Dabbelt wrote: This slipped through the cracks. Probably also NEWS-worthy. gcc/ChangeLog: * doc/invoke.texi (RISC-V): Add -mcmodel=large. OK. And yes, I think we're going to need to to a new/changes update for the port as a whole as part of the gcc-14 pr

Re: [PATCH v3 1/6] RISC-V: Refactor riscv-vector-builtins-bases.cc

On 12/20/23 05:25, Jun Sha (Joshua) wrote: This patch moves the definition of the enums lst_type and frm_op_type into riscv-vector-builtins-bases.h and removes the static visibility of fold_fault_load(), so these can be used in other compile units. gcc/ChangeLog: * config/riscv/riscv

Re: [PATCH v3 2/6] RISC-V: Split csr_operand in predicates.md for vector patterns.

On 12/20/23 05:27, Jun Sha (Joshua) wrote: This patch splits the definition of csr_operand in predicates.md. The newly defined vector_csr_operand has the same functionality as csr_operand but can only be used in vector patterns, so that changes for vector will not affect scalar patterns in fil

Re: [PATCH v3 4/6] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.

On 12/20/23 05:32, Jun Sha (Joshua) wrote: This patch adds th. prefix to all XTheadVector instructions by implementing new assembly output functions. gcc/ChangeLog: * config/riscv/riscv-protos.h (riscv_asm_output_opcode): New function. * config/riscv/riscv.cc (riscv_a

Re: [RFC][V2] RISC-V: Support -mcmodel=large.

On 12/20/23 11:21, Palmer Dabbelt wrote: Yea, the implementation relies largely on just pushing stuff into the constant pool, so we're largely independent ABI stuff with the likely exception being relocations. Ya, but I think we'd only need the relocations if we were going to try relaxing

Re: [PATCH 1/3][RFC] RISC-V: Add non-vector types to pipelines

On 12/15/23 11:53, Edwin Lu wrote: This patch does not create vector related insn reservations for generic.md and sifive-7.md. It updates/creates insn reservations for all non-vector typed insns gcc/ChangeLog: * config/riscv/generic-ooo.md (generic_ooo_sfb_alu): create/update reserv

Re: [PATCH 2/3][RFC] RISC-V: Add vector related reservations

On 12/15/23 11:53, Edwin Lu wrote: This patch copies the vector reservations from generic-ooo.md and inserts them into generic.md and sifive.md. The vector pipelines are necessary to avoid an ICE from the assert gcc/ChangeLog: * config/riscv/generic-ooo.md: syntax * config

Re: [PATCH 3/3][RFC] RISC-V: Enable assert for insn_has_dfa_reservation

On 12/15/23 11:53, Edwin Lu wrote: Enables assert that every typed instruction is associated with a dfa reservation gcc/ChangeLog: * config/riscv/riscv.cc (riscv_sched_variable_issue): enable assert Once the prereqs are in, this is fine. jeff

Re: [PATCH] sel-sched: Verify change before replacing dest in EXPR_INSN_RTX [PR112995]

On 12/15/23 01:52, Kewen.Lin wrote: Hi, PR112995 exposed one issue in current try_replace_dest_reg that the result rtx insn after replace_dest_with_reg_in_expr is probably unable to match any constraints. Although there are some checks on the changes onto dest or src of orig_insn, none is pe

Re: PING^1 [PATCH] sched: Remove debug counter sched_block

On 12/11/23 23:17, Kewen.Lin wrote: Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636597.html BR, Kewen on 2023/11/15 17:01, Kewen.Lin wrote: Hi, on 2023/11/10 01:40, Alexander Monakov wrote: I agree with the concern. I hoped that solving the problem by

Re: [PATCH v3 0/6] RISC-V: Support XTheadVector extension

On 12/20/23 16:08, 钟居哲 wrote: Btw, rv32/rv64gc or rv32/rv64 gcv testing is not enough. We need full coverage testing, since we always commit patch after no regression testing on full coverage testing: No. It is unreasonable to require this large of test matrix for the vast majority if cont

Re: [PATCH v3 0/6] RISC-V: Support XTheadVector extension

On 12/20/23 20:30, juzhe.zh...@rivai.ai wrote: OK.  Sounds reasonable. But from my side, I used to commit patches after full coverage testing. Understood. And it's appreciated -- the code you're doing hits a wide variety of configurations, so the wider testing is probably applicable. Idea

Re: [External] Re: [PATCH] RISC-V: Fix RISCV_FUSE_ZEXTWS fusion condition

On 12/20/23 20:30, Wang Pengcheng wrote: Yeah, I just found it when I tried to understand the original fusion implementation commit. :-) Ah. If you have any questions, don't hesitate to reach out. While I didn't do the original implementation (that was Philipp T. and his team), the basic

Re: [PATCH v3 4/6] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.

On 12/20/23 15:48, 钟居哲 wrote: >> So rather than looking at the mode, would it make more sense to have an attribute (or re-use an existing attribute) to identify which opcodes are going to need prefixing?  We've got access to the INSN via current_output_insn.  So we can lookup attributes triv

Re: [PATCH 1/3][RFC] RISC-V: Add non-vector types to pipelines

On 12/20/23 15:11, Edwin Lu wrote:   (define_insn_reservation "generic_xfer" 3     (and (eq_attr "tune" "generic") -   (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp")) +   (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp,cbo"))     "alu") cbo is probably closer to a load/store than it is a tra

Re: [PATCH v5 2/3] RISC-V: Add crypto machine descriptions

On 12/20/23 20:50, juzhe.zh...@rivai.ai wrote: + (and:VI + (match_operand:VI 3 "register_operand" "vr, vr, vr, vr") + (not:VI (match_operand:VI 4 "register_operand" "vr, vr, vr, vr"))) This order should be swapped like ARM SVE: (define_expand "@cond_bic"   [(se

Re: [PATCH v1] RISC-V: XFail the signbit-5 run test for RVV

On 12/20/23 19:25, pan2...@intel.com wrote: From: Pan Li This patch would like to XFail the signbit-5 run test case for the RVV. Given the case has one limitation like "This test does not work when the truth type does not match vector type." in the beginning of the test file. Aka, the RVV

<    4   5   6   7   8   9   10   11   12   13   >