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

On Tue, 20 May 2025 at 09:10, Tomasz Kaminski wrote: > > > > On Mon, May 19, 2025 at 11:28 PM Nathan Myers wrote: >> +void >> +test02() >> +{ >> + // Test C++26 constructors taking string views using different allocators >> + >> + using alloc_type = __gnu_test::tracker_allocator; > > I would us

Re: [PATCH v1 5/6] libstdc++: Implement layout_stride from mdspan.

On 5/20/25 10:24 AM, Tomasz Kaminski wrote: On Sun, May 18, 2025 at 10:16 PM Luc Grosheintz wrote: Implements the remaining parts of layout_left and layout_right; and all of layout_stride. libstdc++-v3/ChangeLog: * include/std/mdspan(layout_stride): New class. Signed-off-by: Luc

Re: [PATCH v1 5/6] libstdc++: Implement layout_stride from mdspan.

On Tue, May 20, 2025 at 10:45 AM Luc Grosheintz wrote: > > > On 5/20/25 10:24 AM, Tomasz Kaminski wrote: > > On Sun, May 18, 2025 at 10:16 PM Luc Grosheintz < > luc.groshei...@gmail.com> > > wrote: > > > >> Implements the remaining parts of layout_left and layout_right; and all > >> of layout_str

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

On 20/05/2025 05:26, Alexandre Oliva wrote: > 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 func

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

On Tue, 20 May 2025 at 09:10, Tomasz Kaminski wrote: > > > > On Mon, May 19, 2025 at 11:28 PM Nathan Myers wrote: > In the title, we usually put link to bugzilla PR119741 in your case, not the > paper. > Then link the paper in commit descritpion. Right. When there's no bugzilla I'll sometimes p

Re: [PATCH] [testsuite] tolerate missing std::stold

On Tue, 20 May 2025, 05:00 Alexandre Oliva, wrote: > > basic_string.h doesn't define the non-w string version of std::stold > when certain conditions aren't met, and then a couple of tests fail to > compile. > > Guard the portions of the tests that depend on std::stold with the > conditions for i

[PATCH v4 0/4] Hard Register Constraints

This is a follow-up to https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672941.html with basically the only change of adding more tests like for aarch64 and the y constraint or for i386 and constraints S,D,A. I just realized that in the second patch "Error handling for hard register constrai

[PATCH v4 1/4] Hard register constraints

Implement hard register constraints of the form {regname} where regname must be a valid register name for the target. Such constraints may be used in asm statements as a replacement for register asm and in machine descriptions. It is expected and desired that optimizations coalesce multiple pseud

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

> Am 20.05.2025 um 08:48 schrieb 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-

Re: [PATCH 1/5] libstdc++: keep subtree sizes in pb_ds binary search trees (PR 81806)

On 13/07/20 16:40 +0800, Xi Ruoyao via Libstdc++ wrote: The first patch removes two redundant statements which are confusing. It should be applied anyway, disregarding other patches. The patch is attached, to prevent my mail client from destroying it :(. Please ignore a previous duplication o

[PATCH 0/1] Add warnings of potentially-uninitialized padding bits

Commit 0547dbb725b reduced the number of cases in which union padding bits are zeroed when the relevant language standard does not strictly require it, unless gcc was invoked with -fzero-init-padding-bits=unions or -fzero-init-padding-bits=all in order to explicitly request zeroing of padding bits.

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

Konstantinos Eleftheriou writes: > 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 helpe

Re: [PATCH 3/5] libstdc++: keep subtree sizes in pb_ds binary search trees (PR 81806)

On 13/07/20 16:45 +0800, Xi Ruoyao via Libstdc++ wrote: The second and third patch together resolve PR 81806. The attached patch modifies split_finish to use the subtree size we maintained in the previous patch, resolving libstdc++/81806. libstdc++-v3/ChangeLog: PR libstdc++/81806

Re: [PATCH] libgcc: Small bitint_reduce_prec big-endian fixes

On Mon, 19 May 2025, Jakub Jelinek wrote: 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 a

Re: [RFC PATCH 1/3] bitint: Support ABI-extended _BitInt(N)

On Tue, May 20, 2025 at 11:29:10AM +0800, Yang Yujie wrote: > gcc/c-family/ChangeLog: > > * c-common.cc (resolve_overloaded_atomic_exchange): Truncate > _BitInt values before atomic store. You aren't truncating _BitInt values before atomic store, you are extending them. > (reso

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

On Tue, May 20, 2025 at 10:24 AM Luc Grosheintz wrote: > > > On 5/19/25 2:56 PM, Tomasz Kaminski wrote: > > On Sun, May 18, 2025 at 10:14 PM Luc Grosheintz < > luc.groshei...@gmail.com> > > wrote: > > > >> Implements a suite of tests for the currently implemented parts of > >> layout_left. The in

[PATCH 1/2] vect: Remove non-SLP paths in strided slp and elementwise.

This replaces if (slp) with if (1) and if (!slp) with if (0). gcc/ChangeLog: * tree-vect-stmts.cc (vectorizable_load): Make non-slp paths unreachable. --- gcc/tree-vect-stmts.cc | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/gcc/tree-vect-stmts

[PATCH 0/2] vect: Use strided loads for VMAT_STRIDED_SLP.

The second patch adds strided-load support for strided-slp memory access. The first patch makes the respective non-slp paths unreachable. Robin Dapp (2): vect: Remove non-SLP paths in strided slp and elementwise. vect: Use strided loads for VMAT_STRIDED_SLP. gcc/internal-fn.cc

Re: [PATCH v1 5/6] libstdc++: Implement layout_stride from mdspan.

On 5/20/25 10:48 AM, Tomasz Kaminski wrote: On Tue, May 20, 2025 at 10:45 AM Luc Grosheintz wrote: On 5/20/25 10:24 AM, Tomasz Kaminski wrote: On Sun, May 18, 2025 at 10:16 PM Luc Grosheintz < luc.groshei...@gmail.com> wrote: Implements the remaining parts of layout_left and layout_r

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

On Mon, May 19, 2025 at 6:06 PM Patrick Palka wrote: > 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_d

Re: [PATCH v1 5/6] libstdc++: Implement layout_stride from mdspan.

On 5/20/25 11:40 AM, Tomasz Kaminski wrote: On Tue, May 20, 2025 at 11:20 AM Luc Grosheintz wrote: On 5/20/25 10:48 AM, Tomasz Kaminski wrote: On Tue, May 20, 2025 at 10:45 AM Luc Grosheintz < luc.groshei...@gmail.com> wrote: On 5/20/25 10:24 AM, Tomasz Kaminski wrote: On Sun, May

[committed] libstdc++: Cleanup and stabilize format _Spec<_CharT> and _Pres_type.

These patch makes following changes to _Pres_type values: * _Pres_esc is replaced with separate _M_debug flag. * _Pres_s, _Pres_p do not overlap with _Pres_none. * hexadecimal presentation use same values for pointer, integer and floating point types. The members of _Spec<_CharT> are rearran

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

On Mon, May 19, 2025 at 11:28 PM Nathan Myers wrote: In the title, we usually put link to bugzilla *PR119741* in your case, not the paper. Then link the paper in commit descritpion. Add constructors to stringbuf, stringstream, istringstream, >

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

On 5/20/25 4:07 PM, Tomasz Kaminski wrote: On Tue, May 20, 2025 at 3:16 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 Grosheint

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

Changes in v5: * dispatch to starts_with for the both-bidi/common range case Changes in v4: * optimize the both-bidi/common ranges case, as suggested by Tomasz * add tests for that code path Changes in v3: * Use the forward_range code path for a (non-sized) bidirectional haystack,

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

On Tue, 20 May 2025, Patrick Palka wrote: > Changes in v5: > * dispatch to starts_with for the both-bidi/common range case Forgot to mention: And for a bidi common haystack, prefer iterating forward instead of backward if the needle is at least half the size of the haystack, > > Changes in v

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

Thanks Richard for the review. > On 20 May 2025, at 2:47 am, Richard Sandiford > wrote: > > External email: Use caution opening links or attachments > > > Kugan Vivekanandarajah writes: >> diff --git a/Makefile.in b/Makefile.in >> index b1ed67d3d4f..b5e3e520791 100644 >> --- a/Makefile.in >> ++

Re: [PATCH 3/5 v3] c++, coroutines: Address CWG2563 return value init [PR119916].

On 5/20/25 9:42 AM, Iain Sandoe wrote: Hi Jason So I moved this to the position before the g_r_o is initialized (since we only manage cleanups of the entities that come before that, although that's a bit hard to see from the patch). This will probably need reevaluation if you take my suggest

[PATCH] ipa: Fix whitespace when dumping VR in jump_functions

Hi, lack of white space breakes the tree-visualisation structure and makes the dump unnecessarily difficult to read. I have bootstrapped and tested the patch on x86_64-linux. I plan to commit it soon as obvious. Thanks, Martin gcc/ChangeLog: 2025-05-19 Martin Jambor * ipa-prop.c

Re: [PATCH] Add pattern match in match.pd for .AVG_CEIL

On Thu, May 15, 2025 at 10:04 AM liuhongt wrote: > > 1) Optimize (a >> 1) + (b >> 1) + ((a | b) & 1) to .AVG_CEIL (a, b) > 2) Optimize (a | b) - ((a ^ b) >> 1) to .AVG_CEIL (a, b) > > Prof is at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994#c6 > > Bootstrapped and regtested on x86_64-pc-linu

[PATCH] ipa: When inlining, don't combine PT JFs changing signedness (PR120295)

Hi, in GCC 15 we allowed jump-function generation code to skip over a type-cast converting one integer to another as long as the latter can hold all the values of the former or has at least the same precision. This works well for IPA-CP where we do then evaluate each jump function as we propagate

Re: [PATCH v22 0/3] c: Add _Countof and

Hi Joseph, On Tue, May 20, 2025 at 02:43:55PM +, Joseph Myers wrote: > > Could you please clarify if I need to do anything or if this is already > > scheduled for review when you have some time? Also please clarify if > > you're okay with amending that or if you prefer that I send v23. > > I

Re: [RFC PATCH 0/3] _BitInt(N) support for LoongArch

Hi Jakub, Thanks for the quick review. Aside from code formatting issues, can I conclude that you suggest we should rebase this onto your new big-endian support patch? Or do you think it's necessary to add big-endian && extended support together? > Are you sure all those changes were really nec

[PATCH] libstdc++: implement Philox Engine [PR119794]

Implements Philox Engine (P2075R6) and associated tests. Curiously, the ordering for the template unpacking functions caused a bug in which ordering mattered. As such, counter to the recommended style, they are placed in a private classifier prior to the public block. I was unable to find a way ar

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

On Sun, May 18, 2025 at 10:12 PM Luc Grosheintz wrote: > Implements the tests for layout_stride and for the features of the other > two layouts that depend on layout_stride. > > libstdc++-v3/ChangeLog: > > * testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add > tests

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

On Tue, May 20, 2025 at 3:17 PM Tomasz Kaminski wrote: > > > On Tue, May 20, 2025 at 3:07 PM Patrick Palka wrote: > >> On Tue, 20 May 2025, Tomasz Kaminski wrote: >> >> > >> > >> > On Mon, May 19, 2025 at 6:06 PM Patrick Palka >> wrote: >> > On Mon, 19 May 2025, Patrick Palka wrote: >> >

Re: [RFC PATCH 0/3] _BitInt(N) support for LoongArch

On Tue, 2025-05-20 at 15:44 +0200, Jakub Jelinek wrote: > > Specifically, the tests told me to extend (thought "truncate" > > was kind of an equivalent word) the output of left shift, plus/minus, > > Truncation is the exact opposite of extension. > I can understand the need for handling of left sh

[PATCH 4/5 v3] c++, coroutines: Use decltype(auto) for the g_r_o.

Hi Jason, >>>Moving this initialization doesn't seem connected to the type of gro, or >>>mentioned above? >>A fly-by tidy up.. removed. >>I still see it in the new patch? Apologies, I obviously fat-fingered something - done now. >>...return object from an object that has already been destroyed.

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

On Tue, May 20, 2025 at 3:16 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 > --- Sending feedback on this PR

Re: [PATCH 2/2]AArch64: propose -mmax-vectorization as an option to override vector costing

Tamar Christina writes: > Hi All, > > With the middle-end providing a way to make vectorization more profitable by > scaling vect-scalar-cost-multiplier this makes a more user friendly option > to make it easier to use. > > I propose making it an actual -m option that we document and retain vs usi

Re: [PATCH v22 0/3] c: Add _Countof and

On Tue, 20 May 2025, Alejandro Colomar wrote: > Could you please clarify if I need to do anything or if this is already > scheduled for review when you have some time? Also please clarify if > you're okay with amending that or if you prefer that I send v23. I have it on my list for review. I'd

[PATCH v2 1/1] Add warnings of potentially-uninitialized padding bits

Commit 0547dbb725b reduced the number of cases in which union padding bits are zeroed when the relevant language standard does not strictly require it, unless gcc was invoked with -fzero-init-padding-bits=unions or -fzero-init-padding-bits=all in order to explicitly request

[PATCH v2 6/6] libstdc++: Add tests for layout_stride.

Implements the tests for layout_stride and for the features of the other two layouts that depend on layout_stride. libstdc++-v3/ChangeLog: * testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add tests for layout_stride. * testsuite/23_containers/mdspan/layouts/c

[PATCH v2 3/6] libstdc++: Implement layout_right from mdspan.

Implement the parts of layout_left that depend on layout_right; and the parts of layout_right that don't depend on layout_stride. libstdc++-v3/ChangeLog: * include/std/mdspan (layout_right): New class. Signed-off-by: Luc Grosheintz --- libstdc++-v3/include/std/mdspan | 153

[PATCH v2 0/6] Implement layouts from mdspan.

This follows up on: https://gcc.gnu.org/pipermail/libstdc++/2025-May/061459.html The changes are: * Fix layout_stride::strides; and add tests. * Add accessors for ranges of static and dynamic extents. * Use them to implement __fwd_prod and __rev_prod. * Remove public members with protected

[PATCH v2 5/6] libstdc++: Implement layout_stride from mdspan.

Implements the remaining parts of layout_left and layout_right; and all of layout_stride. libstdc++-v3/ChangeLog: * include/std/mdspan(layout_stride): New class. Signed-off-by: Luc Grosheintz --- libstdc++-v3/include/std/mdspan | 211 +++- 1 file changed, 20

[committed] hpux: Fix detection of atomic support when profiling

Tested on hppa64-hp-hpux11.11. Committed to trunk. Dave --- hpux: Fix detection of atomic support when profiling The pa target lacks atomic sync compare and swap instructions. These are implemented as libcalls and in libatomic. As on linux, we lie about their availability. This fixes the gcov

[PATCH v2 0/1] Add warnings of potentially-uninitialized padding bits

Commit 0547dbb725b reduced the number of cases in which union padding bits are zeroed when the relevant language standard does not strictly require it, unless gcc was invoked with -fzero-init-padding-bits=unions or -fzero-init-padding-bits=all in order to explicitly request zeroing of padding bits.

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

I think I do not have any more suggestions for cases to check, so the impl LGTM. On Tue, May 20, 2025 at 4:33 PM Patrick Palka wrote: > Changes in v5: > * dispatch to starts_with for the both-bidi/common range case > > Changes in v4: > * optimize the both-bidi/common ranges case, as suggeste

[committed] libstdc++: Fix incorrect links to archived SGI STL docs

In r8--g25949ee33201f2 I updated some URLs to point to copies of the SGI STL docs in the Wayback Machine, because the original pags were no longer hosted on sgi.com. However, I incorrectly assumed that if one archived page was at https://web.archive.org/web/20171225062613/... then all the other

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

On 5/19/25 2:56 PM, Tomasz Kaminski wrote: 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/

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

On Tue, 20 May 2025, Tomasz Kaminski wrote: > > > On Mon, May 19, 2025 at 6:06 PM Patrick Palka wrote: > 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 s

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

On Tue, May 20, 2025 at 3:07 PM Patrick Palka wrote: > On Tue, 20 May 2025, Tomasz Kaminski wrote: > > > > > > > On Mon, May 19, 2025 at 6:06 PM Patrick Palka wrote: > > On Mon, 19 May 2025, Patrick Palka wrote: > > > > > Changes in v3: > > > * Use the forward_range code path

Re: [RFC PATCH 0/3] _BitInt(N) support for LoongArch

On Tue, May 20, 2025 at 08:58:18PM +0800, Yang Yujie wrote: > Thanks for the quick review. > > Aside from code formatting issues, can I conclude that you suggest > we should rebase this onto your new big-endian support patch? Or > do you think it's necessary to add big-endian && extended support

[PATCH v2 4/6] libstdc++: Add tests for layout_right.

Adds tests for layout_right and for the parts of layout_left that depend on layout_right. libstdc++-v3/ChangeLog: * testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add tests for layout_stride. * testsuite/23_containers/mdspan/layouts/ctors.cc: Add tests for

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

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_containers/mdspan/layouts/class_mandate_neg.cc: New test. * tes

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

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/mdspan | 309 +++- 1 file changed, 308 insert

[PATCH] libgcc: Add DPD support + fix big-endian support of _BitInt <-> dfp conversions

Hi! The following patch fixes FAIL: gcc.dg/dfp/bitint-1.c (test for excess errors) FAIL: gcc.dg/dfp/bitint-2.c (test for excess errors) FAIL: gcc.dg/dfp/bitint-3.c (test for excess errors) FAIL: gcc.dg/dfp/bitint-4.c (test for excess errors) FAIL: gcc.dg/dfp/bitint-5.c (test for excess errors) FAI

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

Changes in V4: * optimize the both-directional/common ranges case, as suggested by Tomasz * add tests for that code path Changes in v3: * Use the forward_range code path for a (non-sized) bidirectional haystack, since it's slightly fewer increments/decrements overall. * Fix wro

[PATCH 3/5 v3] c++, coroutines: Address CWG2563 return value init [PR119916].

Hi Jason >>>So I moved this to the position before the g_r_o is initialized >>>(since we only manage cleanups of the entities that come before that, >>>although >>> that's a bit hard to see from the patch). >>This will probably need reevaluation if you take my suggestion from the >>decltype pat

Re: [PATCH] Match: Handle commonly used unsigned modulo counters

On Thu, May 15, 2025 at 10:29 AM MCC CS wrote: > > Dear all, > > Here's my patch for PR120265. Bootstrapped and tested on aarch64 that it > causes no regressions. I also added a testcase. I'd be grateful > if you could commit it. > > Otherwise, feedback to improve it is welcome. > > Many thanks >

Re: [PATCH v22 0/3] c: Add _Countof and

On Tue, May 20, 2025 at 05:15:33PM +0200, Alejandro Colomar wrote: > I've based on gnulib commits, which I believe follow the same > guidelines. For example: > > commit 6608062398ef4c983a58b90a1520c39f12fb7ac1 > Author: Paul Eggert > Date: Fri Jan 10 10:34:58 2025 -0800 > >

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

On Mon, 19 May 2025, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk/15/14? Whoops, CI reports I missed a testsuite adjustment expecting an additional error in other/default13.C, which seems reasonable. Here's an updated patch. -- >8 -- H

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

Richard Sandiford writes: > Konstantinos Eleftheriou writes: >> 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

Re: [RFC PATCH 0/3] _BitInt(N) support for LoongArch

On Tue, May 20, 2025 at 03:44:09PM +0200, Jakub Jelinek wrote: > The tests weren't included :(. I'd like to see something along the lines of following as the test(s) for the padding bits (if LoongArch will really have the weirdo psABI then with some special version of that for it). Though, this do

[PATCH] fortran: add constant input support for trig functions with half-revolutions

Sorry, the previous patch had some issues with the test case. Please refer to the updated version, which resolves the problem. From: Yuao Ma Sent: Tuesday, May 20, 2025 23:54 To: gcc-patches@gcc.gnu.org ; GCC Fortran ; tbur...@baylibre.com Subject: [PATCH] fort

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

On Tue, 20 May 2025, Tomasz Kaminski wrote: > I think I do not have any more suggestions for cases to check, so the impl > LGTM. It's cool how many optimizations we came up with for this algorithm :) > > On Tue, May 20, 2025 at 4:33 PM Patrick Palka wrote: > Changes in v5: >   * d

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

Changes in v6: * dispatch to starts_with for the bidi haystack + random access needle case too Changes in v5: * dispatch to starts_with for the both-bidi/common range case Changes in v4: * optimize the both-bidi/common ranges case, as suggested by Tomasz * add tests for that code

Re: [PATCH v2 1/1] Add warnings of potentially-uninitialized padding bits

On Tue, 20 May 2025, Christopher Bazley wrote: > + if (!cleared) > + { > + if (complete_p.padded_non_union > + && warn_zero_init_padding_bits >= ZERO_INIT_PADDING_BITS_ALL) > + { > + warning (OPT_Wzero_init_padding_bits_, > +

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

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

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

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

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

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

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

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

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

Maybe I'm missing something there. Particularly whether or not you can know anything about frm's value after a call has returned. Normally the answer to this kind of question is a hard no. AFAICT the main difference to standard mode switching is that we (ab)use it to set the rounding mode to

[PATCH 1/2] [APX CFCMOV] Support APX CFCMOV in if_convert pass

From: Lingling Kong Hi, APX CFCMOV feature implements conditionally faulting which means that all memory faults are suppressed when the condition code evaluates to false and load or store a memory operand. Now we could load or store a memory operand may trap or fault for conditional move. In mi

[PATCH 2/2] [APX CFCMOV] Support APX CFCMOV in backend

From: Lingling Kong gcc/ChangeLog: * config/i386/i386-expand.cc (ix86_expand_int_cfmovcc): Expand to cfcmov pattern. * config/i386/i386-opts.h (enum apx_features): New. * config/i386/i386-protos.h (ix86_expand_int_cfmovcc): Define. * config/i386/i386.cc (

RE: [PUSHED] aarch64: Fix an oversight in aarch64_evpc_reencode

> Pengxuan Zheng writes: > > 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 t

Re: [RFC PATCH 0/3] _BitInt(N) support for LoongArch

On Tue, May 20, 2025 at 09:55:04PM GMT, Xi Ruoyao wrote: > On Tue, 2025-05-20 at 15:44 +0200, Jakub Jelinek wrote: > > > Specifically, the tests told me to extend (thought "truncate" > > > was kind of an equivalent word) the output of left shift, plus/minus, > > > > Truncation is the exact opposit

[PATCH] aarch64: Carry over zeroness in aarch64_evpc_reencode

There was a bug in aarch64_evpc_reencode which could leave zero_op0_p and zero_op1_p of the struct "newd" uninitialized. r16-701-gd77c3bc1c35e303 fixed the issue by zero initializing "newd." This patch provides an alternative fix as suggested by Richard Sandiford based on the fact that the zerone

[PATCH] middle-end: Fix complex lowering of cabs with no LHS [PR120369]

This was introduced by r15-1797-gd8fe4f05ef448e . I had missed that the LHS of the cabs call could be NULL. This seems to only happen at -O0, I tried to produce one that happens at -O1 but needed many different options to prevent the removal of the call. Anyways the fix is just keep around the call

Re: [RFC PATCH 0/3] _BitInt(N) support for LoongArch

On Tue, May 20, 2025 at 03:44:09PM GMT, Jakub Jelinek wrote: > I'd suggest working on it incrementally rather than with a full patch set. > In one or multiple patches handle the promote_mode stuff, the atomic > extension and expr.cc changes with the feedback incorporated. Ok. > For gimple-lower-b

[PATCH v23 1/3] c: Add _Countof operator

This operator is similar to sizeof but can only be applied to an array, and returns its number of elements. FUTURE DIRECTIONS: - We should make it work with array parameters to functions, and somehow magically return the number of elements of the array, regardless of it being really a poin

[PATCH v1 3/3] RISC-V: Add test for vec_duplicate + vand.vv combine case 1 with GR2VR cost 0, 1 and 2

From: Pan Li Add asm dump check test for vec_duplicate + vand.vv combine to vand.vx, with the GR2VR cost is 0, 1 and 2. The below test suites are passed for this patch. * The rv64gcv fully regression test. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-4-i16.c: Add as

[PATCH v1 1/3] RISC-V: RISC-V: Combine vec_duplicate + vand.vv to vand.vx on GR2VR cost

From: Pan Li This patch would like to combine the vec_duplicate + vand.vv to the vand.vx. From example as below code. The related pattern will depend on the cost of vec_duplicate from GR2VR. Then the late-combine will take action if the cost of GR2VR is zero, and reject the combination if the

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

From: Pan Li This patch would like to introduce the combine of vec_dup + vand.vv into vand.vx on the cost value of GR2VR. The late-combine will take place if the cost of GR2VR is zero, or reject the combine if non-zero like 1, 15 in test. There will be two cases for the combine: Case 0: | .

[PATCH v1 2/3] RISC-V: Add test for vec_duplicate + vand.vv combine case 0 with GR2VR cost 0, 2 and 15

From: Pan Li Add asm dump check test for vec_duplicate + vand.vv combine to vand.vx, with the GR2VR cost is 0, 2 and 15. The below test suites are passed for this patch. * The rv64gcv fully regression test. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vx-1-i16.c: Add t

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

The instruction scheduler appears to be speculatively hoisting vsetvl insns outside of their basic block without checking for data dependencies. This resulted in a situation where the following occurs vsetvli a5,a1,e32,m1,tu,ma vle32.v v2,0(a0) sub a1,a1,a5 <-- a1 poten

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

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

Re: [PATCH v22 0/3] c: Add _Countof and

On Tue, May 20, 2025 at 11:44:43PM +0200, Alejandro Colomar wrote: > Hi Jakub, > > On Tue, May 20, 2025 at 11:20:27PM +0200, Jakub Jelinek wrote: > > On Tue, May 20, 2025 at 11:12:38PM +0200, Alejandro Colomar wrote: > > > Okay; how about this? > > > > > > gcc/c-family/ChangeLog: > > > >

Re: [PATCH v22 0/3] c: Add _Countof and

Hi Jakub, On Tue, May 20, 2025 at 11:20:27PM +0200, Jakub Jelinek wrote: > On Tue, May 20, 2025 at 11:12:38PM +0200, Alejandro Colomar wrote: > > Okay; how about this? > > > > gcc/c-family/ChangeLog: > > > > * c-common.h: Add _Countof operator. > > * c-common.def:

[PATCH v23 0/3] c: Add _Countof and

Hi! Here's another revision of this patch set. v23 changes: - More specific change logs. - #define assert() instead of #include'ing . `make check` says all's good. I haven't diffed against master this time, because that's slow as hell, and the changes are minimal. I've only ran `make check

[PATCH v23 3/3] c: Add -Wpedantic diagnostic for _Countof

It has been standardized in C2y. gcc/c/ChangeLog: * c-parser.cc (c_parser_sizeof_or_countof_expression): Add -Wpedantic diagnostic for _Countof in <= C23 mode. gcc/testsuite/ChangeLog: * gcc.dg/countof-compat.c: Test _Countof diagnostics with -Wc23-c2y-compat on

[PATCH v23 2/3] c: Add

gcc/ChangeLog: * Makefile.in (USER_H): Add . * ginclude/stdcountof.h: Add countof macro. gcc/testsuite/ChangeLog: * gcc.dg/countof-stdcountof.c: Add tests for . Signed-off-by: Alejandro Colomar --- gcc/Makefile.in | 1 + gcc/ginclude/stdcount

Re: Fix PR 118541, do not generate unordered fp cmoves for IEEE compares

On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote: > On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote: > > Hi Mike, > > Irrespective of whether -Ofast is used or not, should’nt we generate > > XSCMPUDP instruction for ‘isgreater()’ operation? This is because XSCM

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

> Looks reasonably sensible. But I'll defer to Pan here since he's done > *far* more work than I in this space. Thanks Jeff. LGTM but please wait the ack from Richard for the middle-end change. Pan -Original Message- From: Jeff Law Sent: Wednesday, May 21, 2025 2:06 AM To: Li Xu ; g

[PATCH 2/2] aarch64: Improve rtx_cost for constants in COMPARE [PR120372]

The middle-end uses rtx_cost on constants with the outer of being COMPARE to find out the cost of a constant formation for a comparison instruction. So for aarch64 backend, we would just return the cost of constant formation in general. We can improve this by seeing if the outer is COMPARE and if t

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

This is the first part in fixing PR target/120372. The current code for canonicalize_comparison, uses gen_move_insn and rtx_cost to find out the cost of generating a constant. This is ok in most cases except sometimes the comparison instruction can handle different constants than a simple set intr

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

Thanks Jeff. > So for the tests, why are we forcing matching of the assembly code for > the entire function? That must makes for a fragile test as we may > change various aspects of code generation over time. > If the point of the patch is to detect SAT_ADD in more cases, then the > better an

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

>> I've pushed this to the trunk as well. Thank you Jeff , ~U On Tue, May 20, 2025 at 11:29 PM Jeff Law wrote: > > > On 5/19/25 1:03 AM, Umesh Kalappa wrote: > > --- > > gcc/config/riscv/mips-p8700.md | 28 > > 1 file changed, 28 insertions(+) > I've pushed this

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

>>Thanks. I added the new cpu/tune options to the documentation in doc/invoke.texi. Thank you for the same >>Going forward make sure to create a git commit message as well as a ChangeLog entry. Sure and we make sure that ChangeLog details in the commit log . Thank you again ~U On Tue, May 20, 2

  1   2   >