Re: [PATCH v2] x86: Update memcpy/memset inline strategies for -mtune=generic

> > Perhaps someone is interested in the following thread from LKML: > > "[PATCH v2] x86: prevent gcc from emitting rep movsq/stosq for inlined ops" > > https://lore.kernel.org/lkml/20250605164733.737543-1-mjgu...@gmail.com/ > > There are several PRs regarding memcpy/memset linked from the abov

Re: [PATCH v2] x86: Update memcpy/memset inline strategies for -mtune=generic

On Fri, Jun 13, 2025 at 3:15 PM Cui, Lili wrote: > > > On Mon, Apr 21, 2025 at 7:24 AM H.J. Lu wrote: > > > > > > > > On Sun, Apr 20, 2025 at 6:31 PM Jan Hubicka wrote: > > > > > > > > > > > PR target/102294 > > > > > > PR target/119596 > > > > > > * config/i386/x86-tune-costs

[PATCH v1] RISC-V: Refine VX combine test case 0 to avoid code duplication

From: Pan Li The case 0 for vx combine def functions are most the same across the different test files. Thus, re-arrange them in one place to avoid code duplication. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-1-i16.c: Leverage helper macros to avoid code d

[PATCH] c: Revise -Wjump-misses-init to better support idiomatic C code [PR87038]

Instead of adding it to -Wextra, here is my attempt to improve this  warning as discussed in the PR and make it suitable for -Wall. There were only two tests I had to add -Wno-jump-misses-init. Bootstrapped and regression tested for x86_64. c: Revise -Wjump-misses-init to better support i

Re: [PATCH] Fortran: fix checking of MOLD= in ALLOCATE statements [PR51961]

On 6/15/25 1:22 PM, Harald Anlauf wrote: Am 15.06.25 um 21:25 schrieb Harald Anlauf: Dear all, the attached patch fixes a rejects-valid: in an ALLOCATE statement with MOLD= present, if the allocate-object has an explicit-shape-spec, the compatibility of ranks is not required by the standard.  (

[PATCH] RISC-V: Update profiles string in RV23.

Add b-ext in RVA/B23 as independent extension flags and add supm in RVA23. gcc/ChangeLog: * common/config/riscv/riscv-common.cc: Add b-ext and supm. gcc/testsuite/ChangeLog: * gcc.target/riscv/arch-53.c: Update testcase. --- gcc/common/config/riscv/riscv-common.cc | 6 +++---

Re: [PATCH, part1, v2] Fortran: various fixes for STAT/LSTAT/FSTAT intrinsics [PR82480]

Harald, I did a quick glance at the patch and did not see anything that jumped out as needing a change. OK to commit. Earlier today I came to the same conclusion that -1 on overflow is probably the right thing to do. Gfortran would need a way to supply the value of ERANGE (on all supported targ

Re: [PATCH] xtensa: Revert "xtensa: Eliminate unnecessary general-purpose reg-reg moves"

On Sat, Jun 14, 2025 at 4:31 AM Takayuki 'January June' Suwa wrote: > > Due to improved register allocation for GP registers whose modes has been > changed by paradoxical SUBREGs, the previously committed patch > "xtensa: eliminate unnecessary general-purpose reg-reg moves" > (commit f83e76c3f998c

Re: [PATCH] xtensa: Revert "xtensa: Eliminate unwanted reg-reg moves during DFmode input reloads"

On Sun, Jun 15, 2025 at 2:00 AM Takayuki 'January June' Suwa wrote: > > Since there are no unwanted reg-reg moves during DFmode input reloads in > recent GCCs, the previously committed patch > "xtensa: eliminate unwanted reg-reg moves during DFmode input reloads" > (commit cfad4856fa46abc878934a94

Re: [PATCH v3] simplify-rtx.cc:Simplify XOR(AND(ROTATE(~1) A) ASHIFT(1 A)) to IOR.

Committed to trunk, thanks. Jiawei 在 2025/6/13 21:02, Richard Sandiford 写道: Jiawei writes: This patch adds a new simplification rule to `simplify-rtx.cc` that handles a common bit manipulation pattern involving a single-bit set and clear followed by XOR. The transformation targets RTL of the

RE: [r14-11845 Regression] FAIL: c-c++-common/tsan/tls_race.c -O2 output pattern test on Linux/x86_64

> From: haochen.jiang > Sent: Monday, June 16, 2025 11:42 AM > To: a...@gjlay.de; gcc-regress...@gcc.gnu.org; gcc-patches@gcc.gnu.org; > Jiang, Haochen > > On Linux/x86_64, > > ddf8b0e06f27667b689dbd970d6c4ab0f088d671 is the first bad commit > commit ddf8b0e06f27667b689dbd970d6c4ab0f088d671 >

[PATCH, part1, v2] Fortran: various fixes for STAT/LSTAT/FSTAT intrinsics [PR82480]

Dear all, here's a modification that returns -1 for those components of stat that would overflow assignment to integer(kind=4), and does not return ERANGE as in v1 of this patch. There is no need to modify the existing testcasese stat_{1,2}.f90. Cheers, Harald Am 12.06.25 um 22:12 schrieb Hara

[PATCH] Fortran: fix checking of MOLD= in ALLOCATE statements [PR51961]

Dear all, the attached patch fixes a rejects-valid: in an ALLOCATE statement with MOLD= present, if the allocate-object has an explicit-shape-spec, the compatibility of ranks is not required by the standard. (It is explicitly required only for SOURCE=). Since this could surprise users, we emit

Re: [PATCH] Fortran: fix checking of MOLD= in ALLOCATE statements [PR51961]

Am 15.06.25 um 21:25 schrieb Harald Anlauf: Dear all, the attached patch fixes a rejects-valid: in an ALLOCATE statement with MOLD= present, if the allocate-object has an explicit-shape-spec, the compatibility of ranks is not required by the standard.  (It is explicitly required only for SOURCE=

[r14-11845 Regression] FAIL: c-c++-common/tsan/tls_race.c -O2 output pattern test on Linux/x86_64

On Linux/x86_64, ddf8b0e06f27667b689dbd970d6c4ab0f088d671 is the first bad commit commit ddf8b0e06f27667b689dbd970d6c4ab0f088d671 Author: Georg-Johann Lay Date: Thu Jun 12 10:07:37 2025 +0200 Fix test case for PR117811 which failed for int < 32 bit. caused FAIL: c-c++-common/tsan/tls_rac