Re: [PATCH] defer test for limits.h existence to runtime [PR80677]

Hi Jeff, Thanks for looking at my patch. On Sun, Dec 01, 2024 at 02:40:47PM -0700, Jeff Law wrote: > On 4/30/24 12:45 PM, Helmut Grohne wrote: > > The definition of LIMITS_H_TEST evaluates its existence in > > BUILD_SYSTEM_HEADER_DIR, but we'd actually need it to check a target > > version. Hence

[PATCH] x86: Correct comments for pass_apx_nf_convert

Change pass_rpad to pass_apx_nf_convert in pass_apx_nf_convert comments. * config/i386/i386-features.cc (pass_apx_nf_convert): Change pass_rpad to pass_apx_nf_convert in comments. -- H.J. From e4dd0075aa998d522edd0da552d60a942eaae78a Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Mon, 2 Dec 202

Re: [PATCH] x86: Add a pass to remove redundant all 0s/1s vector load

On Mon, Dec 2, 2024, 11:16 AM Hongtao Liu wrote: > On Sun, Dec 1, 2024 at 7:50 AM H.J. Lu wrote: > > > > For all different modes of all 0s/1s vectors, we can use the single > widest > > all 0s/1s vector register for all 0s/1s vector uses in the whole > function. > > Add a pass to generate a sing

[PATCH v3 3/7] Support for 64-bit location_t: RTL parts

This patch was previously approved in v2. I have included it unchanged here because it cannot be applied until the issue with reemit_insn_block_notes() addressed by patch v3 2/7 is resolved first. -- >8 -- Some RTL objects need to store a location_t. Currently, they store it in the rt_int field o

Re: [PATCH] x86: Add a pass to remove redundant all 0s/1s vector load

On Sun, Dec 1, 2024 at 7:50 AM H.J. Lu wrote: > > For all different modes of all 0s/1s vectors, we can use the single widest > all 0s/1s vector register for all 0s/1s vector uses in the whole function. > Add a pass to generate a single widest all 0s/1s vector set instruction at > entry of the near

[PATCH v3 1/7] middle-end: Handle resized PHI nodes in loop_version()

This patch is my new way to handle what was previously done in v2 patch 04/14, discussed at: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669527.html The only places I have found running into trouble with reallocated PHI nodes (at least, the only places revealed by changing the size of

[PATCH v3 6/7] Support for 64-bit location_t: gimple parts

This patch was previously discussed here: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669437.html This version addresses that feedback, and I have also moved it in the patch ordering to be after the change to 64-bit location_t, since it would be inaccurate prior to that. -- >8 -- The

[PATCH 1/2] RISC-V: Add intrinsics support for SiFive Xsfvfnrclipxfqf extensions.

From: yulong This commit adds intrinsics support for XXsfvfnrclipxfqf. We also redefine the enum type frm_op_type in riscv-vector-builtins-bases.h file, because it be used in sifive-vector-builtins-bases.cc file. Co-Authored by: Jiawei Chen Co-Authored by: Shihua Liao Co-Authored by: Yixuan

[PATCH 2/2] RISC-V: Add intrinsics testcases for SiFive Xsfvfnrclipxfqf extensions.

From: yulong This commit adds testcases for Xsfvfnrclipxfqf. Co-Authored by: Jiawei Chen Co-Authored by: Shihua Liao Co-Authored by: Yixuan Chen gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/xsfvector/sf_vfnrclip_x_f_qf.c: New test. * gcc.target/riscv/rvv/xsfvector/sf_vfnr

[PATCH 0/2] RISC-V: Add intrinsics support and testcases for SiFive Xsfvfnrclipxfqf extension.

From: yulong This patch implements the Sifvie vendor extension Xsfvfnrclipxfqf[1] support to gcc. Providing support for FP32-to-int8 Ranged Clip instrctions. [1] https://www.sifive.com/document-file/fp32-to-int8-ranged-clip-instructions Co-Authored by: Jiawei Chen Co-Authored by: Shihua Liao

[PATCH v3 7/7] Support for 64-bit location_t: Remove -flarge-source-files

This patch was already approved in v2. I have included it here because a) It should not be applied until after the rest of the series, since the option is useful as long as location_t is 32-bit. b) The previous version neglected to regenerate common.opt.urls, which I have co

[PATCH v3 4/7] Support for 64-bit location_t: libgdiagnostics parts

This patch is new in v3 and is a small change to libgdiagnostics similar to other changes required by 64-bit location_t. -- >8 -- Tweak libgdiagnostics.cc, which is necessarily sensitive to line-map internals, to support 64-bit location_t as well. gcc/ChangeLog: * libgdiagnostics.cc (st

[PATCH v3 0/7] Support for 64-bit location_t

Hello- Here is v3 of the 64-bit location_t series. Many of the v2 patches have already been approved and pushed (those that are preparatory and don't change any functionality.) In this series, patches 3 and 7 have already been acked and should not need another review. Patches 1, 2, and 6 are revis

[PATCH v3 5/7] Support for 64-bit location_t: Activate 64-bit location_t

With the codebase having already been prepared to handle it, change location_t to be a 64-bit integer instead of a 32-bit integer. libcpp/ChangeLog: * include/cpplib.h (struct cpp_token): Adjust comment about the struct size. * include/line-map.h (location_t): Change typed

[PATCH v3 2/7] final: Fix call to INSN_LOCATION on a NOTE rtl

This patch was previously discussed at: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670354.html I have attempted to fix it per the feedback in the above thread. Note that this version is a change in behavior. In my v2 patch, I changed it so as to preserve the exact existing behavior --

Re: PING: [PATCH v4 1/7] Honor TARGET_PROMOTE_PROTOTYPES during RTL expand

On Mon, Dec 2, 2024 at 6:39 AM H.J. Lu wrote: > > On Mon, Dec 2, 2024 at 6:15 AM Jeff Law wrote: > > > > > > > > On 11/27/24 3:34 PM, H.J. Lu wrote: > > > On Thu, Nov 21, 2024, 2:02 PM H.J. Lu > > > wrote: > > > > > > Promote integer arguments smaller than int if

Re: [PATCH] Exclude the last named argument for non-variadic function

On Mon, Dec 2, 2024 at 6:20 AM Jeff Law wrote: > > > > On 11/1/24 12:53 AM, H.J. Lu wrote: > > expand_call has > > > > /* Now possibly adjust the number of named args. > > Normally, don't include the last named arg if anonymous args follow. > > We do include the last named arg if > >

Re: [PATCH] Add new hardreg PRE pass

On 11/13/24 12:03 PM, Richard Sandiford wrote: Andrew Carlotti writes: I think this is mostly my ignorance of the code, and would be obvious if I tried it out locally, but: why do we need to do this after computing the kills bitmap? For mode-switching, the kills bitmap is the inverse of

Re: [PATCH] Add new hardreg PRE pass

On Sun, Dec 1, 2024 at 2:36 PM Jeff Law wrote: > > > > On 11/12/24 3:42 PM, Richard Sandiford wrote: > > >> + > >> +bool > >> +pass_hardreg_pre::gate (function *fun) > >> +{ > >> +#ifdef HARDREG_PRE_REGNOS > >> + return optimize > 0 > >> +&& !fun->calls_setjmp; > > > > Huh. It looks like the

Re: PING: [PATCH v4 1/7] Honor TARGET_PROMOTE_PROTOTYPES during RTL expand

On Mon, Dec 2, 2024 at 6:15 AM Jeff Law wrote: > > > > On 11/27/24 3:34 PM, H.J. Lu wrote: > > On Thu, Nov 21, 2024, 2:02 PM H.J. Lu > > wrote: > > > > Promote integer arguments smaller than int if TARGET_PROMOTE_PROTOTYPES > > returns true. > > > >

Re: [PATCH] Add new hardreg PRE pass

On 11/12/24 3:42 PM, Richard Sandiford wrote: + +bool +pass_hardreg_pre::gate (function *fun) +{ +#ifdef HARDREG_PRE_REGNOS + return optimize > 0 +&& !fun->calls_setjmp; Huh. It looks like these setjmp exclusions go back to 1998. I wouldn't have expected them to be needed now, since

Re: [PATCH] x86: Add pcmpeq splitters

On Sun, Dec 1, 2024 at 8:01 PM Uros Bizjak wrote: > > On Sat, Nov 30, 2024 at 11:00 PM H.J. Lu wrote: > > > > Add pcmpeq splitters to split > > > > (insn 5 3 7 2 (set (reg:V4SI 100) > > (eq:V4SI (reg:V4SI 98) > > (reg:V4SI 98))) 7910 {*sse2_eqv4si3} > > (expr_list:REG_DEA

[PATCH] Fix non-aligned CodeView symbols

CodeView symbols in PDB files are aligned to four-byte boundaries. It's not really clear what logic MSVC uses to enforce this; sometimes the symbols are padded in the object file, sometimes the linker seems to do the work. It makes more sense to do this in the compiler, so fix the two instances wh

[PATCH v2] x86: Add pcmpeq splitters

Add pcmpeq splitters to split (insn 5 3 7 2 (set (reg:V4SI 100) (eq:V4SI (reg:V4SI 98) (reg:V4SI 98))) 7910 {*sse2_eqv4si3} (expr_list:REG_DEAD (reg:V4SI 98) (expr_list:REG_EQUAL (eq:V4SI (const_vector:V4SI [ (const_int -1 [0xfff

Re: [PATCH] Add new hardreg PRE pass

On 11/12/24 3:42 PM, Richard Sandiford wrote: Sorry for the slow review. I think Jeff's much better placed to comment on this than I am, but here's a stab. Mostly it looks really good to me FWIW. Digging out. I'll try to get a good looksie this afternoon/evening. jeff

Re: [PATCH] Exclude the last named argument for non-variadic function

On 11/1/24 12:53 AM, H.J. Lu wrote: expand_call has /* Now possibly adjust the number of named args. Normally, don't include the last named arg if anonymous args follow. We do include the last named arg if targetm.calls.strict_argument_naming() returns nonzero. (If n

Re: PING: [PATCH v4 1/7] Honor TARGET_PROMOTE_PROTOTYPES during RTL expand

On 11/27/24 3:34 PM, H.J. Lu wrote: On Thu, Nov 21, 2024, 2:02 PM H.J. Lu > wrote: Promote integer arguments smaller than int if TARGET_PROMOTE_PROTOTYPES returns true.         PR middle-end/14907         * calls.c (initialize_argument_informatio

Re: [PATCH] defer test for limits.h existence to runtime [PR80677]

On 4/30/24 12:45 PM, Helmut Grohne wrote: The definition of LIMITS_H_TEST evaluates its existence in BUILD_SYSTEM_HEADER_DIR, but we'd actually need it to check a target version. Hence this check occasionally produces misdetections when build and target differ. In some cases such as cygming, t

Re: [patch,avr,testsuite,applied] gcc.c-torture/execute/memcpy-a*.c

Am 01.12.24 um 19:15 schrieb Dimitar Dimitrov: On Sun, Dec 01, 2024 at 12:32:55PM +0100, Georg-Johann Lay wrote: Am 01.12.24 um 05:45 schrieb Maciej W. Rozycki: On Sat, 30 Nov 2024, Georg-Johann Lay wrote: The gcc.c-torture/execute/memcpy-a[1248].c tests consumed more time than the whole rest

Re: [PING] [contrib] validate_failures.py: fix python 3.12 escape sequence warnings

On 11/22/24 11:19 AM, Sam James wrote: Jeff Law writes: On 6/9/24 5:45 AM, Gabi Falk wrote: Hi, On Sat, Jun 08, 2024 at 03:34:02PM -0600, Jeff Law wrote: On 5/14/24 8:12 AM, Gabi Falk wrote: Hi, This one still needs review: https://inbox.sourceware.org/gcc-patches/20240415233833.104460

Re: [PATCH] gcc: configure: Fix the optimization flags cleanup

On 2/2/24 9:02 AM, Slava Barinov wrote: Currently sed command in flag cleanup removes all the -O[0-9] flags, ignoring the context. This leads to issues when the optimization flags is passed to linker: CFLAGS="-Os -Wl,-O1 -Wl,--hash-style=gnu" is converted into CFLAGS="-Os -Wl,-Wl,--hash-style

Re: [patch,avr,testsuite,applied] gcc.c-torture/execute/memcpy-a*.c

On Sun, Dec 01, 2024 at 12:32:55PM +0100, Georg-Johann Lay wrote: > Am 01.12.24 um 05:45 schrieb Maciej W. Rozycki: > > On Sat, 30 Nov 2024, Georg-Johann Lay wrote: > > > > > The gcc.c-torture/execute/memcpy-a[1248].c tests consumed more time > > > than the whole rest of the test suite, just to co

Re: [PATCH v2] phi-opt: Add missed optimization for "(cond | (a != b)) ? b : a"

[ Thanks for your patience. It's been a long month ;-) ] On 11/4/24 6:23 AM, Jovan Vukic wrote: On 11/02/24, Jeff Law wrote: This is well understood. The key in my mind is that for AND we always select the FALSE arm. For IOR we always select the TRUE arm. Yes, I agree. e = (cod

[committed] Patches 8-12 of Mariam & Matevos's CRC optimization work

[ Resent with compressed patches to get undre the 400k limit. ] This is the bulk of Mariam's & Matevos's work on CRC optimization. It covers detection, validation and final transformation of a bitwise CRC loop into an IFN. Once in IFN form the expansion code from earlier this week can expand

[PATCH] RISC-V: Introduce vector lowering of VEC_PERM_EXPR for large vector types

This patch introduces partial vectorization support for VEC_PERM_EXPR when vector types specified are not supported on some architectures because of their size. Take, for instance, this vector type: typedef int32_t vnx32si __attribute__ ((vector_size (128))); For -march=rv64gcv_zvl256b GCC doesn'

[committed] testsuite: Silence gcc.dg/pr117806.c for default_packed

On default_packed targets like PRU, spurious warnings are emitted: ...workspace/gcc/gcc/testsuite/gcc.dg/pr117806.c:5:3: warning: 'packed' attribute ignored for field of type 'double' [-Wattributes] Fix by annotating the excess warnings for default_packed targets. Pushed to trunk as obvious.

Re: [PATCH] x86: Add pcmpeq splitters

On Sat, Nov 30, 2024 at 11:00 PM H.J. Lu wrote: > > Add pcmpeq splitters to split > > (insn 5 3 7 2 (set (reg:V4SI 100) > (eq:V4SI (reg:V4SI 98) > (reg:V4SI 98))) 7910 {*sse2_eqv4si3} > (expr_list:REG_DEAD (reg:V4SI 98) > (expr_list:REG_EQUAL (eq:V4SI (const_vector

Re: [patch,avr,testsuite,applied] gcc.c-torture/execute/memcpy-a*.c

Am 01.12.24 um 05:45 schrieb Maciej W. Rozycki: On Sat, 30 Nov 2024, Georg-Johann Lay wrote: The gcc.c-torture/execute/memcpy-a[1248].c tests consumed more time than the whole rest of the test suite, just to come up with a "memory full" even at -Os. Skipped thusly. As a matter of interest, i

Stage 1 patch ping (D, C++, libstdc++, toplevel, driver)

Hi, I'd like to ping the following patches sent in stage1: https://inbox.sourceware.org/20240414001113.1698685-1-ar...@aarsen.me - Area: Toplevel - Subject: Recover in-tree libiconv build support https://inbox.sourceware.org/20240918210202.192478-1-ar...@aarsen.me - Area: C++, libstdc++ - Subjec