[PATCH] [testsuite] [x86] strlenopt-80 needs -msse2 on ia32

2025-05-19 Thread Alexandre Oliva
The string length optimizations at 8-byte blocks requires -msse2; -msse is not enough. Bump it. Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-, arm-, x86-, and x86_64-vxworks7r2. Ok to install? for gcc/testsuite/ChangeLog * gcc.dg/strlenopt-80.c: Bump to -mss

[PATCH] [testsuite] [x86] memcpy-6 needs -msse2

2025-05-19 Thread Alexandre Oliva
The 8-byte memory operations will only be inlined on ia32 with -msse2. Bump it. Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-, arm-, x86-, and x86_64-vxworks7r2. Ok to install? for gcc/testsuite/ChangeLog * memcpy-6.c: Bump to -msse2. --- gcc/testsuite/gcc.

[PATCH] [testsuite] add missing require vect_early_break_hw for vect-tsvc

2025-05-19 Thread Alexandre Oliva
Some tsvc tests add vect_early_break options without requiring the feature to be available. Add the requirements. Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-, arm-, x86-, and x86_64-vxworks7r2. Ok to install? for gcc/testsuite/ChangeLog * gcc.dg/vect/tsvc/

Re: [PATCH v3 2/3] sbitmap: Add bitmap_is_range_set_p function

2025-05-19 Thread Konstantinos Eleftheriou
Hi Richard, thanks for your response. On Tue, May 20, 2025 at 8:05 AM Richard Biener wrote: > > On Mon, May 19, 2025 at 4:14 PM Konstantinos Eleftheriou > wrote: > > > > This patch adds the `bitmap_is_range_set_p` function in sbitmap, > > which checks if all the bits in a range are set. This fun

[PATCH] [testsuite] [x86] double copysign requires -msse2

2025-05-19 Thread Alexandre Oliva
SSE_FLOAT_MODE_P only holds for DFmode with SSE2, and that's a condition for copysign3 to be available under TARGET_SSE_MATH. Various copysign testcases use -msse -mfpmath=sse on ia32 to enable the copysign builtins and patterns, but that would only be enough if the tests were limited to floats.

[PATCH] [testsuite] [x86] vect-simd-clone-1[678]e.c adjust

2025-05-19 Thread Alexandre Oliva
Since r13-6296, we haven't got 4 simdclone calls for these tests on ia32 without avx_runtime. With avx_runtime, we get 3 such calls even on ia32, but we didn't test for anything on ia32 with avx_runtime. Adjust and simplify the expectations and comments. Regstrapped on x86_64-linux-gnu. Also t

[PATCH] [testsuite] [x86] no-callee-saved-16.c needs -fomit-frame-pointer

2025-05-19 Thread Alexandre Oliva
If the toolchain is built with --enable-frame-pointer, gcc.target/i386/no-callee-saved-16.c will not get the expected optimization without -fomit-frame-pointer, that would be enabled by -O2 without the configure flag. Add it. Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-

[PATCH] [testsuite] [arm] adjust fp16-aapcs for gcc-14

2025-05-19 Thread Alexandre Oliva
(The backport I've only just posted is not enough for the tests to pass; there's another problem) r14-10824 is a backport of r15-4549, that rewrote and extended into check-function-bodies the save/restore expectations introduced in r15-2160. Alas, r15-2160 mentions an insn_propagation patch tha

[PATCH] [testsuite] [x86] pr108938-3.c needs -msse2 for bswap in foo2 with -m32

2025-05-19 Thread Alexandre Oliva
Without SSE2, we don't combine the separate loads in foo2 and get separate rotates, instead of a bswap. Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-, arm-, x86-, and x86_64-vxworks7r2. Ok to install? for gcc/testsuite/ChangeLog * gcc.target/i386/pr108938-3.c

[PATCH] [testsuite] [x86] pr31985.c needs -fomit-frame-pointer to match movl count

2025-05-19 Thread Alexandre Oliva
On an --enable-frame-pointer toolchain, pr31985.c gets an extra movl and fails. Enable -fomit-frame-pointer explicitly. Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-, arm-, x86-, and x86_64-vxworks7r2. Ok to install? for gcc/testsuite/ChangeLog * gcc.target/

Re: [PATCH] [testsuite] add missing require vect_early_break_hw for vect-tsvc

2025-05-19 Thread Richard Biener
OK On Tue, May 20, 2025 at 6:20 AM Alexandre Oliva wrote: > > > Some tsvc tests add vect_early_break options without requiring the > feature to be available. Add the requirements. > > Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-, > arm-, x86-, and x86_64-vxworks7r2. Ok

Re: [PATCH] [testsuite] [ppc] add -mpowerpc-gfxopt or -mcmpb to copysign tests

2025-05-19 Thread Alexandre Oliva
On May 8, 2025, Alexandre Oliva wrote: > * gcc.dg/fold-copysign-1.c: Add -mcmpb on ppc. Uhh, sorry, I've accidentally dropped this bit from the patch posted a couple of weeks ago. Here it is. BTW, Ping? https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683066.html diff --git a/gcc/te

[PATCH] [testsuite] [x86] forwprop-41 needs -msse

2025-05-19 Thread Alexandre Oliva
The vector operations are only turned into BIT_INSERT_EXPR with -msse on ia32. Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-, arm-, x86-, and x86_64-vxworks7r2. Ok to install? for gcc/testsuite/ChangeLog * gcc.dg/tree-ssa/forwprop-41.c: Add -msse on x86. ---

Re: [PATCH v3 2/3] sbitmap: Add bitmap_is_range_set_p function

2025-05-19 Thread Richard Biener
On Mon, May 19, 2025 at 4:14 PM Konstantinos Eleftheriou wrote: > > This patch adds the `bitmap_is_range_set_p` function in sbitmap, > which checks if all the bits in a range are set. This function > calls `bitmap_bit_in_range_p_1`, which has been updated to use > the `any_inverted` parameter. Whe

[PATCH] [gcc-14] testsuite: Improve check-function-bodies

2025-05-19 Thread Alexandre Oliva
The backport of commit 205515da82a2914d765e74ba73fd2765e1254112 to gcc-14 as 8b1146fe46e62f8b03bd9ddee48995794e192e82, rewriting gcc.target/arm/fp16-aapcs-[1234].c into check-function-bodies, requires the following patch for the one-character function names used in those tests. Tested with gcc-14

RE: [PATCH][RFC] Allow the target to request a masked vector epilogue

2025-05-19 Thread Richard Biener
On Mon, 19 May 2025, Tamar Christina wrote: -Original Message- From: Richard Biener Sent: Friday, May 16, 2025 11:35 AM To: gcc-patches@gcc.gnu.org Cc: Richard Sandiford ; Tamar Christina Subject: [PATCH][RFC] Allow the target to request a masked vector epilogue Targets recently got t

Re: [PATCH] [testsuite] add missing require vect_early_break_hw for vect-tsvc

2025-05-19 Thread Uros Bizjak
LGTM for the whole series. Thanks, Uros. On Tue, May 20, 2025 at 6:17 AM Alexandre Oliva wrote: > > > Some tsvc tests add vect_early_break options without requiring the > feature to be available. Add the requirements. > > Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-, >

Re: [PATCH] tree-chrec: Use signed_type_for in convert_affine_scev

2025-05-19 Thread Richard Biener
On Mon, 19 May 2025, Jakub Jelinek wrote: Hi! On s390x-linux I've run into the gcc.dg/torture/bitint-27.c test ICEing in build_nonstandard_integer_type called from convert_affine_scev (not sure why it doesn't trigger on x86_64/aarch64). The problem is clear, when ct is a BITINT_TYPE with some l

[PATCH] libgcc: Move bitint support exports to x86/aarch64 specific map files

2025-05-19 Thread Jakub Jelinek
Hi! When adding _BitInt support I was hoping all or most of arches would implement it already for GCC 14. That didn't happen and with new hosts adding support for _BitInt for GCC 16 (s390x-linux and as was posted today loongarch-linux too), we need the _BitInt support functions exported on those

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

2025-05-19 Thread Umesh Kalappa
>>Every type listed in that attribute must have a mapping to a function unit in >>your scheduler model Thank you Jeff and added the dummies reservation for the leftout attributes and tested with dejagnu riscv.exp. Thank you again for reference ~U

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

2025-05-19 Thread Umesh Kalappa
--- gcc/config/riscv/mips-p8700.md | 28 1 file changed, 28 insertions(+) diff --git a/gcc/config/riscv/mips-p8700.md b/gcc/config/riscv/mips-p8700.md index 11d0b1ca793..ae0ea8dc896 100644 --- a/gcc/config/riscv/mips-p8700.md +++ b/gcc/config/riscv/mips-p8700.md @@ -3

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

2025-05-19 Thread Dongyan Chen
During the GCC compilation, some warnings about temporary object dangling references emerged. They appeared in these code lines in riscv-common.cc: const riscv_ext_info_t &implied_ext_info, const riscv_ext_info_t &ext_info = get_riscv_ext_info (ext) and auto &ext_info = get_riscv_ext_info (search

[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.

2025-05-19 Thread Umesh Kalappa
--- 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 +- 5 files changed, 170 insertions(+), 2 deletions

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

2025-05-19 Thread Dongyan Chen
I fix the code by changing the argument type of get_riscv_ext_info to `const char *` and the link is: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684057.html 在 2025/5/16 10:35, Kito Cheng 写道: Hm, it really doesn't make too much sense to get that warning, but I can reproduce that whe

[PATCH] cobol: fix minor grammar in comments

2025-05-19 Thread pulk66-s
--- gcc/cobol/lexio.cc | 2 +- gcc/cobol/parse.y | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/cobol/lexio.cc b/gcc/cobol/lexio.cc index 2db1af273e9..4f68bf65887 100644 --- a/gcc/cobol/lexio.cc +++ b/gcc/cobol/lexio.cc @@ -1455,7 +1455,7 @@ cdftext::lex_open( const

Re: [PATCH 3/5] ipa: Dump cgraph_node UID instead of order into ipa-clones dump file

2025-05-19 Thread Martin Jambor
Hello, On Thu, May 15 2025, Jan Hubicka wrote: >> Hi, >> >> starting with GCC 15 the order is not unique for any symtab_nodes but >> m_uid is, I believe we ought to dump the latter in the ipa-clones dump, >> if only so that people can reliably match entries about new clones to >> those about remo

Re: [PATCH] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Tomasz Kaminski
On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote: I would appreciate a short explanation on the approach being put here, in the message. Like passing -1 as means of saying, size not know. Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > >From the non-stylistic changes, I have noti

Re: [PATCH] libstdc++: Fix some Clang -Wsystem-headers warnings in

2025-05-19 Thread Tomasz Kaminski
On Fri, May 16, 2025 at 7:35 PM Jonathan Wakely wrote: > libstdc++-v3/ChangeLog: > > * include/std/ranges (_ZipTransform::operator()): Remove name of > unused parameter. > (chunk_view::_Iterator, stride_view::_Iterator): Likewise. > (join_with_view): Declare _Itera

Re: [PATCH] libstdc++: Fix std::format of chrono::local_days with {} [PR120293]

2025-05-19 Thread Tomasz Kaminski
On Fri, May 16, 2025 at 7:33 PM Jonathan Wakely wrote: > Formatting of chrono::local_days with an empty chrono-specs should be > equivalent to inserting it into an ostream, which should use the > overload for inserting chrono::sys_days into an ostream. The > implementation of empty chrono-specs i

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

2025-05-19 Thread Jin Ma
On Sun, 16 Mar 2025 11:23:07 -0600, Jeff Law wrote: > > > On 3/10/25 2:26 AM, Kito Cheng wrote: > > This patch fixes the multilib_os_dir and multiarch_dir for those targets > > that use TARGET_COMPUTE_MULTILIB, since the TARGET_COMPUTE_MULTILIB hook > > only update/fix the multilib_dir but not th

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

2025-05-19 Thread Kito Cheng
Pushed to trunk :) On Mon, May 19, 2025 at 3:18 PM Dongyan Chen wrote: > > During the GCC compilation, some warnings about temporary object dangling > references emerged. They appeared in these code lines in riscv-common.cc: > const riscv_ext_info_t &implied_ext_info, const riscv_ext_info_t &ext

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

2025-05-19 Thread Li Xu
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; \ return (x ^ IMM) < 0

[PATCH 1/2] Match:Support signed vector SAT_ADD IMM form 1

2025-05-19 Thread Li Xu
From: xuli This patch would like to support vector SAT_ADD when one of the op is singed IMM. void __attribute__((noinline)) \ vec_sat_s_add_imm_##T##_fmt_1##_##INDEX (T *out, T *op_1, unsigned limit) \ {

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

2025-05-19 Thread Li Xu
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) \ {\ unsigned i;

Re: [PATCH] RISC-V: Rename conflicting variables in gen-riscv-ext-texi.cc

2025-05-19 Thread Kito Cheng
Committed to trunk, thanks :) On Mon, May 19, 2025 at 10:44 AM Songhe Zhu wrote: > > From: zhusonghe > > The variables `major` and `minor` in `gen-riscv-ext-texi.cc` > conflict with the macros of the same name defined in ``, > which are exposed when building with newer versions of GCC on older >

Re: [PATCH] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Tomasz Kaminski
On Mon, May 19, 2025 at 11:29 AM Jonathan Wakely wrote: > On Mon, 19 May 2025 at 05:46, Patrick Palka wrote: > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > > > -- >8 -- > > > > libstdc++-v3/ChangeLog: > > > > * include/bits/ranges_algo.h (__starts_with_fn, starts

Re: [PATCH] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Jonathan Wakely
On Mon, 19 May 2025 at 05:46, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > -- >8 -- > > libstdc++-v3/ChangeLog: > > * include/bits/ranges_algo.h (__starts_with_fn, starts_with): > Define. > (__ends_with_fn, ends_with): Define. >

Re: [PATCH][RFC] Allow the target to request a masked vector epilogue

2025-05-19 Thread Richard Sandiford
Richard Biener writes: > On Fri, 16 May 2025, Richard Sandiford wrote: >> > The simple prototype below uses a separate flag from the epilogue >> > mode, but I wonder how we want to more generally want to handle >> > whether to use masking or not when iterating over modes. Currently >> > we mostly

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

2025-05-19 Thread Richard Sandiford
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 such? > > I don't think there should be an

Re: [AUTOFDO][AARCH64] Add support for profilebootstrap

2025-05-19 Thread Kugan Vivekanandarajah
> On 16 May 2025, at 12:10 am, Andi Kleen wrote: > > External email: Use caution opening links or attachments > > > On Wed, May 14, 2025 at 02:46:15AM +, Kugan Vivekanandarajah wrote: >> Adding Eugene and Andi to CC as Sam suggested. >> >>> On 13 May 2025, at 12:57 am, Richard Sandiford >>

[r16-334 Regression] FAIL: gcc.dg/Wincompatible-pointer-types-1.c (test for excess errors) on Linux/x86_64

2025-05-19 Thread haochen.jiang
On Linux/x86_64, b6d37ec1dd2a228d94e7b5b438f3aa53684316bc is the first bad commit commit b6d37ec1dd2a228d94e7b5b438f3aa53684316bc Author: Florian Weimer Date: Thu May 1 19:06:45 2025 +0200 c: Suppress -Wdeprecated-non-prototype warnings for builtins caused FAIL: gcc.c-torture/compile/cal

Re: [PATCH] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Jonathan Wakely
On Mon, 19 May 2025 at 10:35, Tomasz Kaminski wrote: > > > > On Mon, May 19, 2025 at 11:29 AM Jonathan Wakely wrote: >> >> On Mon, 19 May 2025 at 05:46, Patrick Palka wrote: >> > >> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? >> > >> > -- >8 -- >> > >> > libstdc++-v3/ChangeLog:

Re: [PATCH v1 0/8] RISC-V: Combine vec_duplicate + vrsub.vv to vrsub.vx on GR2VR cost

2025-05-19 Thread Robin Dapp
The series LGTM. I didn't check all the tests in detail to be honest :) -- Regards Robin

RE: [PATCH 1/2]middle-end: Apply loop->unroll directly in vectorizer

2025-05-19 Thread Tamar Christina
> >/* Complete the target-specific cost calculations. */ > >loop_vinfo->vector_costs->finish_cost (loop_vinfo->scalar_costs); > >vec_prologue_cost = loop_vinfo->vector_costs->prologue_cost (); > > @@ -12373,6 +12394,13 @@ vect_transform_loop (loop_vec_info loop_vinfo, > gimple *loop_ve

Re: Add effective-target 'offload_device_usm', 'libgomp.c-c++-common/target-usm-1.c'

2025-05-19 Thread Tobias Burnus
Hi Thomas, coming back to the patch itself – having sent comments in previous email. As mentioned, I think you either want to have: * Check whether the runtime knows that USM is supported for the default device (that is a non-host device), i.e. a no-host device is available with 'required uni

Re: [PATCH v1 1/6] libstdc++: Implement layout_left from mdspan.

2025-05-19 Thread Tomasz Kaminski
On Sun, May 18, 2025 at 10:11 PM Luc Grosheintz wrote: > Implements the parts of layout_left that don't depend on any of the > other layouts. > > libstdc++-v3/ChangeLog: > > * include/std/mdspan (layout_left): New class. > > Signed-off-by: Luc Grosheintz > --- > libstdc++-v3/include/std

RE: [PATCH 1/2]middle-end: Add new parameter to scale scalar loop costing in vectorizer

2025-05-19 Thread Tamar Christina
> > +-param=vect-scalar-cost-multiplier= > > +Common Joined UInteger Var(param_vect_scalar_cost_multiplier) Init(1) > IntegerRange(0, 10) Param Optimization > > +The scaling multiplier to add to all scalar loop costing when performing > vectorization profitability analysis. The default value i

[PATCH 1/2] Match:Support IMM=-1 for signed scalar SAT_ADD IMM form1

2025-05-19 Thread Li Xu
From: xuli This patch would like to support .SAT_ADD when IMM=-1. Form1: T __attribute__((noinline)) \ sat_s_add_imm_##T##_fmt_1##_##INDEX (T x) \ {\ T sum = (UT)x + (UT)IMM; \ return (x ^ IMM) < 0

[PATCH] c++/modules: Ensure vtables are emitted when needed [PR120349]

2025-05-19 Thread Nathaniel Shead
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Alternatively could go back to always marking vtables as DECL_EXTERNAL as well but that doesn't seem to be necessary that I can tell. -- >8 -- I missed a testcase in r16-688-gc875748cdc468e for whether a GM vtable should be emitted

Re: [PATCH v1 2/6] libstdc++: Add tests for layout_left.

2025-05-19 Thread Tomasz Kaminski
On Sun, May 18, 2025 at 10:14 PM Luc Grosheintz wrote: > Implements a suite of tests for the currently implemented parts of > layout_left. The individual tests are templated over the layout type, to > allow reuse as more layouts are added. > > libstdc++-v3/ChangeLog: > > * testsuite/23_co

Re: [PATCH v1 0/6] Implement layouts from mdspan.

2025-05-19 Thread Tomasz Kaminski
Thank you for the patches. I have reviewed the layout_left and test, and posted some suggestions there. I will follow up with a review for other mapping later. On Sun, May 18, 2025 at 10:07 PM Luc Grosheintz wrote: > Technically, this is the second iteration of these patches. Previous > discussi

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

2025-05-19 Thread Jeff Law
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). This cause

[GCC15][committed] OpenMP - backporting testcases + 2 mapping fixes

2025-05-19 Thread Tobias Burnus
The next two commits fix two mapping issues, the rest are test cases that should have been in GCC 15 pre-branch. Namely: r15-9707-g57f73c3956572f   OpenMP/Fortran: Fix allocatable-component mapping of derived-type array comps r15-9706-gab9ca3a8b1af41   OpenMP: Fix mapping of zero-sized arrays w

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

2025-05-19 Thread Jeff Law
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] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Tomasz Kaminski
On Mon, May 19, 2025 at 9:59 AM Tomasz Kaminski wrote: > > > On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote: > I would appreciate a short explanation on the approach being put here, > in the message. Like passing -1 as means of saying, size not know. > > Tested on x86_64-pc-linux-gnu, does

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

2025-05-19 Thread Jeff Law
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 suc

Re: [PATCH] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Patrick Palka
On Mon, 19 May 2025, Tomasz Kaminski wrote: > > > On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote: > I would appreciate a short explanation on the approach being put here,  > in the message. Like passing -1 as means of saying, size not know. > > Tested on x86_64-pc-linux-gnu, does th

Re: [PATCH] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Tomasz Kaminski
On Mon, May 19, 2025 at 4:02 PM Patrick Palka wrote: > On Mon, 19 May 2025, Tomasz Kaminski wrote: > > > > > > > On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote: > > I would appreciate a short explanation on the approach being put here, > > in the message. Like passing -1 as means of saying,

[PATCH v3 2/3] sbitmap: Add bitmap_is_range_set_p function

2025-05-19 Thread Konstantinos Eleftheriou
This patch adds the `bitmap_is_range_set_p` function in sbitmap, which checks if all the bits in a range are set. This function calls `bitmap_bit_in_range_p_1`, which has been updated to use the `any_inverted` parameter. When `any_inverted` is true, the helper function checks if any of the bits in

[PATCH v3 0/3] asf: Fix ICE on emit_move_insn [PR119884]

2025-05-19 Thread Konstantinos Eleftheriou
During the base register initialization, when we are eliminating the load instruction, we were calling `emit_move_insn` on registers of the same size but of different mode in some cases, causing an ICE. We update the base register initialization to use `lowpart_subreg` instead of zero-extending th

[PATCH v3 1/3] sbitmap: Add bitmap_bit_in_range_p_1 helper function

2025-05-19 Thread Konstantinos Eleftheriou
This patch adds the `bitmap_bit_in_range_p_1` helper function, in order to be used by `bitmap_bit_in_range_p`. The helper function contains the previous implementation of `bitmap_bit_in_range_p` and `bitmap_bit_in_range_p` has been updated to call the helper function. gcc/ChangeLog: * sbi

[PATCH v2] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Patrick Palka
Changes in v2: Addressed Tomasz's review comments, namely: * Added explicit iter_difference_t casts * Made _S_impl member private * Optimized sized bidirectional case of ends_with * Rearranged control flow of starts_with::_S_impl Still left to do: * Add tests for integer-class types

[PATCH v3 3/3] asf: Fix calling of emit_move_insn on registers of different modes [PR119884]

2025-05-19 Thread Konstantinos Eleftheriou
This patch uses `lowpart_subreg` for the base register initialization, instead of zero-extending it. We had tried this solution before, but we were leaving undefined bytes in the upper part of the register. This shouldn't be happening as we are supposed to write the whole register when the load is

[PATCH] c++/modules: Always mark tinfo vars as TREE_ADDRESSABLE [PR120350]

2025-05-19 Thread Nathaniel Shead
Regtested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk if full bootstrap+regtest succeeds? And maybe 15? -- >8 -- We need to mark type info decls as addressable if we take them by reference; this is done by walking the declaration during parsing and marking the decl as needed.

Re: [PATCH] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Tomasz Kaminski
On Mon, May 19, 2025 at 4:05 PM Patrick Palka wrote: > On Mon, 19 May 2025, Tomasz Kaminski wrote: > > > > > > > On Mon, May 19, 2025 at 9:59 AM Tomasz Kaminski > wrote: > > > > > > On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote: > > I would appreciate a short explanation on the approach b

Re: [PATCH] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Tomasz Kaminski
On Mon, May 19, 2025 at 4:09 PM Tomasz Kaminski wrote: > > > On Mon, May 19, 2025 at 4:02 PM Patrick Palka wrote: > >> On Mon, 19 May 2025, Tomasz Kaminski wrote: >> >> > >> > >> > On Mon, May 19, 2025 at 6:47 AM Patrick Palka >> wrote: >> > I would appreciate a short explanation on the approac

Re: [PATCH v2] asf: Fix calling of emit_move_insn on registers of different modes [PR119884]

2025-05-19 Thread Konstantinos Eleftheriou
Hi Richard, thanks again for the feedback. We have sent an updated version, which removes the redundant store operations (https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684096.html). This one is a series as we needed to update sbitmap with a function that checks if a range in the bitmap is set

Re: [PATCH 5/5 v2] c++, coroutines: Clean up the ramp cleanups.

2025-05-19 Thread Jason Merrill
On 5/16/25 10:15 AM, Iain Sandoe wrote: Hi Jason, + = build1_loc (loc, TRUTH_NOT_EXPR, boolean_type_node, iarc_x); + do_fr_cleanup = build2_loc (loc, TRUTH_AND_EXPR, boolean_type_node, + do_fr_cleanup, coro_before_return); This also needs reversing

Re: [PATCH v2] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Patrick Palka
On Mon, 19 May 2025, Patrick Palka wrote: > Changes in v2: > Addressed Tomasz's review comments, namely: > * Added explicit iter_difference_t casts > * Made _S_impl member private > * Optimized sized bidirectional case of ends_with > * Rearranged control flow of starts_with::_S_impl > >

Re: [PATCH v3 1/3] sbitmap: Add bitmap_bit_in_range_p_1 helper function

2025-05-19 Thread Philipp Tomsich
On Mon, 19 May 2025 at 16:10, Konstantinos Eleftheriou wrote: > > This patch adds the `bitmap_bit_in_range_p_1` helper function, > in order to be used by `bitmap_bit_in_range_p`. The helper function > contains the previous implementation of `bitmap_bit_in_range_p` and > `bitmap_bit_in_range_p` has

Re: [PATCH v2] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Tomasz Kaminski
On Mon, May 19, 2025 at 4:11 PM Patrick Palka wrote: > Changes in v2: > Addressed Tomasz's review comments, namely: > * Added explicit iter_difference_t casts > * Made _S_impl member private > * Optimized sized bidirectional case of ends_with > * Rearranged control flow of starts_with::

[PING][PATCH v3] reassoc: Optimize CMP/XOR expressions [PR116860]

2025-05-19 Thread Konstantinos Eleftheriou
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677788.html . Thanks, Konstantinos

Re: [PATCH] asf: Fix calling of emit_move_insn on registers of different modes [PR119884]

2025-05-19 Thread Konstantinos Eleftheriou
On Wed, May 7, 2025 at 11:29 AM Richard Sandiford wrote: > > Konstantinos Eleftheriou writes: > > Hi Richard, > > > > Thanks for the feedback! We have sent a new version that uses > > lowpart_subreg > > (https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682835.html). > > We had tried that befor

Re: [PATCH v6 1/3][Middle-end] Provide more contexts for -Warray-bounds, -Wstringop-*warning messages due to code movements from compiler transformation (Part 1) [PR109071, PR85788, PR88771, PR106762,

2025-05-19 Thread Richard Biener
On Fri, May 16, 2025 at 3:34 PM Qing Zhao wrote: > > Control this with a new option -fdiagnostics-details. > > $ cat t.c > extern void warn(void); > static inline void assign(int val, int *regs, int *index) > { > if (*index >= 4) > warn(); > *regs = val; > } > struct nums {int vals[4];}; >

[PATCH v3] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Patrick Palka
Changes in v3: * Use the forward_range code path for a (non-sized) bidirectional haystack, since it's slightly fewer increments/decrements overall. * Fix wrong iter_difference_t cast in starts_with. Changes in v2: Addressed Tomasz's review comments, namely: * Added explicit iter_di

Re: [PATCH v2] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Patrick Palka
On Mon, 19 May 2025, Tomasz Kaminski wrote: > > > On Mon, May 19, 2025 at 4:11 PM Patrick Palka wrote: > Changes in v2: >   Addressed Tomasz's review comments, namely: >   * Added explicit iter_difference_t casts >   * Made _S_impl member private >   * Optimized si

Re: [PATCH v2] c++, coroutines: Use decltype(auto) for the g_r_o.

2025-05-19 Thread Jason Merrill
On 5/16/25 10:11 AM, Iain Sandoe wrote: Hi Jason, + returned reference or prvalue result object ... + When we use a local to hold this, it is decltype(auto). */ + tree gro_type += finish_decltype_type (get_ro, /*id_expression_or_member_access_p*/true, This should be false, not

Re: [PATCH v3] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Patrick Palka
On Mon, 19 May 2025, Patrick Palka wrote: > Changes in v3: > * Use the forward_range code path for a (non-sized) bidirectional > haystack, since it's slightly fewer increments/decrements > overall. > * Fix wrong iter_difference_t cast in starts_with. > > Changes in v2: > Addressed T

Re: [PATCH v2] c++, coroutines: Address CWG2563 return value init [PR119916].

2025-05-19 Thread Jason Merrill
On 5/16/25 10:04 AM, Iain Sandoe wrote: + /* We must manage the cleanups ourselves, because the responsibility for + them changes after the initial suspend. However, any use of + cxx_maybe_build_cleanup () can set the throwing_cleanup flag. */ + cp_function_chain->throwing_cleanup = f

Re: [PATCH] c++/modules: Always mark tinfo vars as TREE_ADDRESSABLE [PR120350]

2025-05-19 Thread Jason Merrill
On 5/19/25 9:37 AM, Nathaniel Shead wrote: Regtested on x86_64-pc-linux-gnu (so far just modules.exp), OK for trunk if full bootstrap+regtest succeeds? And maybe 15? OK for both. -- >8 -- We need to mark type info decls as addressable if we take them by reference; this is done by walking th

Re: [PATCH v2] c++, coroutines: Use decltype(auto) for the g_r_o.

2025-05-19 Thread Jason Merrill
On 5/19/25 11:54 AM, Jason Merrill wrote: On 5/16/25 10:11 AM, Iain Sandoe wrote: Hi Jason, + returned reference or prvalue result object ... + When we use a local to hold this, it is decltype(auto).  */ +  tree gro_type +    = finish_decltype_type (get_ro, / *id_expression_or_member_

Re: [PATCH] libstdc++: Implement C++23 P1659R3 starts_with and ends_with

2025-05-19 Thread Patrick Palka
On Mon, 19 May 2025, Tomasz Kaminski wrote: > > > On Mon, May 19, 2025 at 9:59 AM Tomasz Kaminski wrote: > > > On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote: > I would appreciate a short explanation on the approach being put here,  > in the message. Like passing -1 as means of saying,

[PATCH] arm: fully validate mem_noofs_operand [PR120351]

2025-05-19 Thread Richard Earnshaw
It's not enough to just check that a memory operand is of the form mem(reg); after RA we also need to validate the register being used. The safest way to do this is to call memory_operand. PR target/120351 gcc/ChangeLog: * config/arm/predicates.md (mem_noofs_operand): Also check

Re: [AUTOFDO][AARCH64] Add support for profilebootstrap

2025-05-19 Thread Richard Sandiford
Kugan Vivekanandarajah writes: > diff --git a/Makefile.in b/Makefile.in > index b1ed67d3d4f..b5e3e520791 100644 > --- a/Makefile.in > +++ b/Makefile.in > @@ -4271,7 +4271,7 @@ all-stageautoprofile-bfd: configure-stageautoprofile-bfd > $(HOST_EXPORTS) \ > $(POSTSTAGE1_HOST_EXPORTS) \ >

Re: [PATCH] Fortran: fix FAIL of gfortran.dg/specifics_1.f90 after r16-372 [PR120099]

2025-05-19 Thread Harald Anlauf
Pushed as r16-734-gbf98b735ae01c6 after an off-list OK by Jerry, and no other responses to the opposite. Harald On 5/18/25 22:53, Harald Anlauf wrote: Dear all, the attached proposed patch fixes PR120099 by modifying gfc_return_by_reference so that it returns true with -ff2c also for intrinsic

[PUSHED] aarch64: Fix an oversight in aarch64_evpc_reencode

2025-05-19 Thread Pengxuan Zheng
Some fields (e.g., zero_op0_p and zero_op1_p) of the struct "newd" may be left uninitialized in aarch64_evpc_reencode. This can cause reading of uninitialized data. I found this oversight when testing my patches on and/fmov optimizations. This patch fixes the bug by zero initializing the struct. P

[PATCH] libgcc: Small bitint_reduce_prec big-endian fixes

2025-05-19 Thread Jakub Jelinek
Hi! The big-endian _BitInt support in libgcc was written without any testing and so I haven't discovered I've made one mistake in it (in multiple places). The bitint_reduce_prec function attempts to optimize inputs which have some larger precision but at runtime they are found to need smaller numb

[PATCH] tree-chrec: Use signed_type_for in convert_affine_scev

2025-05-19 Thread Jakub Jelinek
Hi! On s390x-linux I've run into the gcc.dg/torture/bitint-27.c test ICEing in build_nonstandard_integer_type called from convert_affine_scev (not sure why it doesn't trigger on x86_64/aarch64). The problem is clear, when ct is a BITINT_TYPE with some large TYPE_PRECISION, build_nonstandard_intege

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

2025-05-19 Thread Jeff Law
As Mark and I independently tripped, there's a Wuninitialized issue in the RISC-V backend. While *I* know the value would always be properly initialized, it'd be somewhat painful to either eliminate the infeasible paths or do deep enough analysis to suppress the false positive. So this initia

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

2025-05-19 Thread Jeff Law
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

[PUSHED] Fix libgomp.oacc-fortran/lib-13.f90 async bug

2025-05-19 Thread Thomas Schwinge
From: Julian Brown libgomp/ * testsuite/libgomp.oacc-fortran/lib-13.f90: End data region after wait API calls. --- libgomp/testsuite/libgomp.oacc-fortran/lib-13.f90 | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libgomp/testsuite/libgomp.oacc-fortra

[PUSHED] Add 'libgomp.c-c++-common/target-abi-struct-1-O0.c', 'libgomp.oacc-c-c++-common/abi-struct-1.c'

2025-05-19 Thread Thomas Schwinge
libgomp/ * testsuite/libgomp.c-c++-common/target-abi-struct-1-O0.c: New. * testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c: Likewise. --- .../target-abi-struct-1-O0.c | 3 + .../libgomp.oacc-c-c++-common/abi-struct-1.c | 96 +++ 2 files

Re: [PATCH v6 0/3][Middle-end]Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

2025-05-19 Thread Kees Cook
On Fri, May 16, 2025 at 01:34:14PM +, Qing Zhao wrote: > Adding -fdiagnotics-details into GCC to provide more hints to the > end users on how the warnings come from, in order to help the user > to locate the exact location in source code on the specific warnings > due to compiler optimizations.

[PUSHED] 'TYPE_EMPTY_P' vs. code offloading [PR120308]

2025-05-19 Thread Thomas Schwinge
We've got 'gcc/stor-layout.cc:finalize_type_size': /* Handle empty records as per the x86-64 psABI. */ TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type); (Indeed x86_64 is still the only target to define 'TARGET_EMPTY_RECORD_P', calling 'gcc/tree.cc-default_is_empty_record'.) An

Re: [patch, fortran] PR120049 - ICE when using IS_C_ASSOCIATED ()

2025-05-19 Thread Harald Anlauf
Hi Jerry, so contrary to what the name of patch claims (pr120049-final.diff), it fixes only the case of direct use of iso_c_binding, but not the indirect one thru the other module, which is the reason for the original ICE and the PR. So if you want to push the incremental patch now, go ahead. C

Re: [PATCH] c++/modules: Ensure vtables are emitted when needed [PR120349]

2025-05-19 Thread Jason Merrill
On 5/19/25 8:27 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Alternatively could go back to always marking vtables as DECL_EXTERNAL as well but that doesn't seem to be necessary that I can tell. DECL_NOT_REALLY_EXTERN doesn't make sense without DE

Re: [PATCH] c++/modules: Fix ICE on merge of instantiation with partial spec [PR120013]

2025-05-19 Thread Jason Merrill
On 5/17/25 10:38 AM, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15? OK. -- >8 -- When we import a pending instantiation that matches an existing partial specialisation, we don't find the slot in the entity map because for partial specialisations we

[PATCH] libstdc++: Implement stringstream from string_view [P2495R3]

2025-05-19 Thread Nathan Myers
Add constructors to stringbuf, stringstream, istringstream, and ostringstream, and a matching overload of str(sv) in each, that take anything convertible to a string_view where the existing functions take a string. libstdc++-v3/ChangeLog: P2495R3 stringstream to init from string_view-ish

[PATCH] libstdc++: Implement stringstream from string_view [P2495R3]

2025-05-19 Thread Nathan Myers
Add constructors to stringbuf, stringstream, istringstream, and ostringstream, and a matching overload of str(sv) in each, that take anything convertible to a string_view where the existing functions take a string. libstdc++-v3/ChangeLog: P2495R3 stringstream to init from string_view-ish

[PATCH] c++: substituting fn parm redeclared with dep alias tmpl [PR120224]

2025-05-19 Thread Patrick Palka
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/15/14? -- >8 -- Here we declare f twice, first ordinarily and then using a dependent alias template. Due to alias template transparency these logically declare the same overload. But now the function type of f, which

  1   2   >