Re: [PATCH V3] x86: Enable separate shrink wrapping

Hi! On Tue, Jun 17, 2025 at 10:03:28PM +0800, Cui, Lili wrote: > Collected spec2017 performance on ZNVER5, EMR and ICELAKE. No performance > regression was observed. > For O2 multi-copy : > 511.povray_r improved by 2.8% on ZNVER5. > 511.povray_r improved by 4.2% on EMR No huge improvement, but n

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 11:07:31AM -0700, Steve Kargl wrote: > On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote: > > > > === gfortran Summary === > > > > # of expected passes73149 > > # of unexpected failures522 It seems that something is mucking wi

Re: [PATCH v6 14/19] c++: Fix FMV return type ambiguation

On 6/12/25 11:03 AM, Alfie Richards wrote: Add logic for the case of two FMV annotated functions with identical signature other than the return type. Previously this was ignored, this changes the behavior to emit a diagnostic. gcc/cp/ChangeLog: PR c++/119498 * decl.cc (duplic

Re: [PATCH] expand: Allow reuse of local memory for tail call argument [PR42909]

On Sun, Jun 29, 2025, 12:18 PM Jeff Law wrote: > > > On 6/27/25 12:16 AM, Andrew Pinski wrote: > > Since after a tail call function (even if it is tail called in the end), > > the current function does not care about the local memory any more so > > there is no reason to do a copy of the argument

Re: [PATCH] RISC-V: Vector-scalar negate-multiply-(subtract-)accumulate [PR119100]

On 6/26/25 8:53 AM, Paul-Antoine Arras wrote: This pattern enables the combine pass (or late-combine, depending on the case) to merge a vec_duplicate into a (possibly negated) minus-mult RTL instruction. Before this patch, we have two instructions, e.g.: vfmv.v.fv6,fa0 vfnmacc.v

Re: [PATCH v6 11/19] c/c++: Add target_[version/clones] to decl diagnostics formatting.

On 6/12/25 11:00 AM, Alfie Richards wrote: Adds the target_version and target_clones attributes to diagnostic messages for target_version semantics. This is because the target_version/target_clones attributes affect the identity of the decls, so need to be represented in diagnostics for them.

Re: [PATCH v6 09/19] fmv: Add reject_target_clone hook for filtering target_clone versions.

On 6/12/25 11:00 AM, Alfie Richards wrote: This patch introduces the TARGET_REJECT_FUNCTION_CLONE_VERSION hook which is used to determine if a target_clones version string parses. If true is returned, a warning is emitted and from then on the version is ignored. This is as specified in the A

Re: [PATCH v6 08/19] riscv: Refactor riscv target parsing to take string_slice.

On 6/12/25 11:00 AM, Alfie Richards wrote: This is a quick refactor of the riscv target processing code to take a string_slice rather than a decl. The reason for this is to enable it to work with target_clones where merging logic requires reasoning about each version string individually in th

Re: [PATCH] expand: Allow reuse of local memory for tail call argument [PR42909]

On 6/27/25 12:16 AM, Andrew Pinski wrote: Since after a tail call function (even if it is tail called in the end), the current function does not care about the local memory any more so there is no reason to do a copy of the argument. This is only true for the first usage of the decl, the rest

Re: [PATCH v2] RISC-V: Refactor the function bitmap_union_of_preds_with_entry

On 6/28/25 6:07 AM, Jin Ma wrote: The current implementation of this function is somewhat difficult to understand, as it uses a direct break statement within the for loop, rendering the loop meaningless. Additionally, during the Coverity check on the for loop, a warning appeared: "unreachable:

Re: [PATCH V1] RISC-V:Add the MIPS P8700 conditional move extension instruction support.

On 6/13/25 9:01 AM, Umesh Kalappa wrote: Addressed the most of comments and tried to refactor the riscv_expand_conditional_move() to some extent. No regressions are found for "runtest --tool gcc --target_board='riscv-sim/-mabi=lp64d/-mtune=mips-p8700/-O2 ' riscv.exp" *config/riscv/

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 08:36:38PM +0200, Andre Vehreschild wrote: > > I would do git am pr88076_v1_1.patch or patch -p1 each of the patch files. Then they go where they ought to be. Thanks. I needed -p1 for v1_5 and v1_6. > Pro tip: create a new branch before doing the git am, then you can ju

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Steve, I would do git am pr88076_v1_1.patch or patch -p1 each of the patch files. Then they go where they ought to be. Pro tip: create a new branch before doing the git am, then you can just switch back to master when desired. - Andre Andre Vehreschild * ve...@gmx.de Am 29. Juni 2025 20:2

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote: > > Just applied the 6 patch (with the update part 5). I'm > seeing a significant increase in the number of failures > in 'make check-fortran' testing. > Just re-applied your patches in the top-level gcc/ directory. I was expecting mo

Re: [PATCH] c++: Fix up cp_build_array_ref COND_EXPR handling [PR120471]

On 6/28/25 3:08 AM, Jakub Jelinek wrote: On Fri, Jun 27, 2025 at 06:49:12PM -0400, Jason Merrill wrote: On 6/27/25 5:58 PM, Jakub Jelinek wrote: The following testcase is miscompiled since the introduction of UBSan, cp_build_array_ref COND_EXPR handling replaces (cond ? a : b)[idx] with cond ?

Re: [PATCH RFC] libgcc: don't use a weak ref for __cxa_finalize

On 6/28/25 3:17 PM, Florian Weimer wrote: * Jason Merrill: Since r10-6069[1] we control the call to __cxa_finalize with DEFAULT_USE_CXA_ATEXIT, so there's no need to also declare it as a weak reference; if the target has __cxa_atexit, it must also have __cxa_finalize. I expect that most targe

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote: > > === gfortran Summary === > > # of expected passes73149 > # of unexpected failures522 > # of expected failures 343 > # of unresolved testcases 78 > # of unsupported tests 94

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Thu, Jun 26, 2025 at 10:15:01AM +0200, Andre Vehreschild wrote: > > I deem this library fit for educational and research use, > where small to medium sized problems are researched. I do > not expect it to support a long term running application, > because is does not join adjacent blocks in th

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Tue, Jun 24, 2025 at 03:09:33PM +0200, Andre Vehreschild wrote: > > this series of patches (six in total) adds a new coarray backend library to > libgfortran. The library uses shared memory and processes to implement > running multiple images on the same node. The work is based on work starte

Re: [PATCH v2] expand: Allow sibcalling for return structures in some cases [PR71761]

On 6/25/25 8:58 PM, Andrew Pinski wrote: In the case of tailing call with a return of a structure, currently all large structures are rejected. We can allow the case were the return of the "tail call" function is setting the return value of the current function. This allows for the musttail t

Re: [PATCH] lra: Check for null lowpart_subregs [PR120733]

On 6/24/25 4:30 AM, Richard Sandiford wrote: lra-eliminations.cc:move_plus_up tries to: Transform (subreg (plus reg const)) to (plus (subreg reg) const) when it is possible. Most of it is heavily conditional: if (!paradoxical_subreg_p (x) && GET_CODE (subreg_reg) == PLUS

Re: [PATCH] [testsuite] restore default action from dfp.exp [PR120631]

On 6/26/25 1:08 AM, Alexandre Oliva wrote: dfp.exp tests for dfprt before deciding whether to default to run or compile, and the PR120631 tests override that without checking for dfprt. Rework them to avoid attempting to link and run programs when dfp runtime support isn't available. Tested

Re: [PATCH][RFC] phiopt: Optimize A < 0 ? ARG1 OP 2^n-1 : ARG1

On 6/28/25 2:36 PM, Andrew Pinski wrote: On Sat, Jun 28, 2025, 1:19 PM Jeff Law > wrote: On 6/27/25 12:20 PM, Andrew Pinski wrote: > > > > I have been trying to most of the phiopt to over to use match and > simplify (via match.p

Re: [PATCH] x86: Preserve frame pointer for no_callee_saved_registers attribute

"H.J. Lu" writes: > Update functions with no_callee_saved_registers/preserve_none attribute > to preserve frame pointer since caller may use it to save the current > stack: > > pushq %rbp > movq %rsp, %rbp > ... > call function > ... > leave > ret > > If callee changes frame pointer without resto

Re: [PATCH][RFC] phiopt: Optimize A < 0 ? ARG1 OP 2^n-1 : ARG1

On Sat, Jun 28, 2025, 1:19 PM Jeff Law wrote: > > > On 6/27/25 12:20 PM, Andrew Pinski wrote: > > > > > > > > > I have been trying to most of the phiopt to over to use match and > > simplify (via match.pd patterns). Is there an issue why this can't be a > > match pattern instead? It seems like a

Re: [PATCH][RFC] phiopt: Optimize A < 0 ? ARG1 OP 2^n-1 : ARG1

On 6/27/25 12:20 PM, Andrew Pinski wrote: I have been trying to most of the phiopt to over to use match and simplify (via match.pd patterns). Is there an issue why this can't be a match pattern instead? It seems like a good fit too. It should simplify the code added even. I can certai

Re: [PATCH] Add "void debug (tree)"

On Sun, Jun 29, 2025 at 3:42 AM Jeff Law wrote: > > > > On 6/27/25 10:24 PM, H.J. Lu wrote: > > On Sat, Jun 28, 2025 at 12:03 PM Jeff Law wrote: > >> > >> > >> > >> On 6/27/25 5:34 PM, H.J. Lu wrote: > >>> Add "void debug (tree)" to support: > >>> > >>> (gdb) call debug (expr) > >>> >>>

Re: [PATCH] Add "void debug (tree)"

On 6/27/25 10:24 PM, H.J. Lu wrote: On Sat, Jun 28, 2025 at 12:03 PM Jeff Law wrote: On 6/27/25 5:34 PM, H.J. Lu wrote: Add "void debug (tree)" to support: (gdb) call debug (expr) unit-size user align:256 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type

Re: [PATCH RFC] libgcc: don't use a weak ref for __cxa_finalize

* Jason Merrill: > Since r10-6069[1] we control the call to __cxa_finalize with > DEFAULT_USE_CXA_ATEXIT, so there's no need to also declare it as a weak > reference; if the target has __cxa_atexit, it must also have __cxa_finalize. I expect that most targets do not need __cxa_finalize. They can

Re: [PATCH] Add "void debug (tree)"

> Am 28.06.2025 um 01:36 schrieb H.J. Lu : > > Add "void debug (tree)" to support: > > (gdb) call debug (expr) > type size >unit-size >user align:256 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type > 0x7fffe99cebd0 >fields double> >X

Re: [PATCH] c++: Fix up cp_build_array_ref COND_EXPR handling [PR120471]

On Fri, Jun 27, 2025 at 06:49:12PM -0400, Jason Merrill wrote: > On 6/27/25 5:58 PM, Jakub Jelinek wrote: > > The following testcase is miscompiled since the introduction of UBSan, > > cp_build_array_ref COND_EXPR handling replaces > > (cond ? a : b)[idx] with cond ? a[idx] : b[idx], but if there a

Re: [PATCH 04/17] ranger: Mark several member functions as final override

Martin Jambor writes: > Hi, > > When GCC is built with clang, it emits warnings that several member > functions of various ranger classes override a virtual function of an > ancestor but are not marked with the override keyword. After > inspecting the cases, I found that all these classes had ot

Re: [PATCH] Add "void debug (tree)"

On Sat, Jun 28, 2025 at 12:03 PM Jeff Law wrote: > > > > On 6/27/25 5:34 PM, H.J. Lu wrote: > > Add "void debug (tree)" to support: > > > > (gdb) call debug (expr) > >> type > size > > unit-size > > user align:256 warn_if_not_align:0 symtab:0 alias-set -1 >

Re: [PATCH] Add "void debug (tree)"

On 6/27/25 5:34 PM, H.J. Lu wrote: Add "void debug (tree)" to support: (gdb) call debug (expr) unit-size user align:256 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffe99cebd0 fields XF x.c:2:15 size unit-

Re: [PATCH V3] x86: Enable separate shrink wrapping

nt...@gmail.com; Michael Matz > > ; Sam James ; kenjin4...@gmail.com > > Subject: RE: [PATCH V3] x86: Enable separate shrink wrapping > > > > > -Original Message- > > > From: H.J. Lu > > > Sent: Friday, June 27, 2025 4:48 PM > > > To:

RE: [PATCH v3 0/4] RISC-V: Combine vec_duplicate + vssubu.vv to vssubu.vx on GR2VR cost

The CI reported 2 failures but seems unrelated and passed locally, thus will commit this before the end of next Monday(6/30) if no more concerns. > FAIL: gcc.dg/vect/pr115669.c -flto -ffat-lto-objects (test for excess errors) Executing on host: /home/lipan/gnu-toolchain/build/build-riscv64-unkn

Re: [PATCH 15/17] coroutines: Removed unused private member in cp_coroutine_transform

On 6/25/25 10:22 AM, Iain Sandoe wrote: On 25 Jun 2025, at 15:17, Martin Jambor wrote: Hi, when building GCC with clang, it warns that the private member suffix in class cp_coroutine_transform (defined in gcc/cp/coroutines.h) is not used which indeed looks like it is the case. This patch t

Re: [PATCH] c++: Fix up cp_build_array_ref COND_EXPR handling [PR120471]

On 6/27/25 5:58 PM, Jakub Jelinek wrote: Hi! The following testcase is miscompiled since the introduction of UBSan, cp_build_array_ref COND_EXPR handling replaces (cond ? a : b)[idx] with cond ? a[idx] : b[idx], but if there are SAVE_EXPRs inside of idx, they will be evaluated just in one of the

Re: [PATCH] c++/modules: Ensure type of partial spec VAR_DECL is consistent with its template [PR120644]

On 6/27/25 3:28 AM, Nathaniel Shead wrote: On Wed, Jun 25, 2025 at 11:52:14AM -0400, Jason Merrill wrote: On 6/25/25 9:02 AM, Nathaniel Shead wrote: On Tue, Jun 24, 2025 at 12:10:09PM -0400, Patrick Palka wrote: On Tue, 24 Jun 2025, Jason Merrill wrote: On 6/23/25 5:41 PM, Nathaniel Shead wr

Re: [PATCH v2] c++: fix ICE with [[deprecated]] [PR120756]

On 6/26/25 4:12 PM, Marek Polacek wrote: On Wed, Jun 25, 2025 at 03:13:25PM -0400, Jason Merrill wrote: On 6/25/25 1:28 PM, Marek Polacek wrote: @@ -24604,7 +24604,7 @@ resolve_nondeduced_context (tree orig_expr, tsubst_flags_t complain) } if (good == 1) { - ma

Re: [PATCH] c++, v3: Implement C++26 P3533R2 - constexpr virtual inheritance [PR120777]

On Fri, Jun 27, 2025 at 05:17:55PM -0400, Jason Merrill wrote: > I've pushed those changes. Great. > > /* For a non-pointer simple base reference, express it as a > > COMPONENT_REF > >without taking its address (and so causing lambda capture, 91933). > > */ > > - if (code == PLUS_

Re: [PATCH 1/4] c++: Add flag to detect underlying representative of bitfield decls

On 6/27/25 5:03 AM, Nathaniel Shead wrote: On Wed, Jun 25, 2025 at 01:05:39PM -0400, Jason Merrill wrote: On 5/21/25 10:14 PM, Nathaniel Shead wrote: This patch isn't currently necessary with how I've currently done the follow-up patches, but is needed for avoiding any potential issues in the f

Re: [PATCH] c++, v3: Implement C++26 P3533R2 - constexpr virtual inheritance [PR120777]

On 6/27/25 5:17 PM, Jason Merrill wrote: On 6/26/25 1:30 PM, Jakub Jelinek wrote: On Thu, Jun 26, 2025 at 01:33:08PM +0200, Jakub Jelinek wrote: I get some regressions (which I didn't get with the earlier patch, but it isn't obvious by what it has been caused): It ICEs were caused by the cano

Re: [PATCH] c++, v3: Implement C++26 P3533R2 - constexpr virtual inheritance [PR120777]

On 6/26/25 1:30 PM, Jakub Jelinek wrote: On Thu, Jun 26, 2025 at 01:33:08PM +0200, Jakub Jelinek wrote: I get some regressions (which I didn't get with the earlier patch, but it isn't obvious by what it has been caused): It ICEs were caused by the canonicalize_obj_off change and indeed The IC

Re: [PATCH, part2] Fortran: follow-up fix to checking of renamed-on-use interface name [PR120784]

Am 27.06.25 um 22:57 schrieb Jerry D: On 6/27/25 1:48 PM, Harald Anlauf wrote: Dear all, my original patch caused a regression on previously working code where an imported interface was *not* renamed-on-use, as the related new logic did not expect a local_name to be an empty string. Funnily, t

Re: [PATCH, part2] Fortran: follow-up fix to checking of renamed-on-use interface name [PR120784]

On 6/27/25 1:48 PM, Harald Anlauf wrote: Dear all, my original patch caused a regression on previously working code where an imported interface was *not* renamed-on-use, as the related new logic did not expect a local_name to be an empty string. Funnily, there was no previously existing test in

Re: [PATCH][RFC] phiopt: Optimize A < 0 ? ARG1 OP 2^n-1 : ARG1

On 6/27/25 12:30 PM, Andrew Pinski wrote: On Fri, Jun 27, 2025, 11:06 AM Raphael Moreira Zinsly mailto:rzin...@ventanamicro.com>> wrote: Hi all, For targets that have expensive shifts this may not get a better sequence right now, specially for AVR and MSP430 according to

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,PR1

On Fri, Jun 27, 2025 at 01:38:51PM +, Qing Zhao wrote: > The good news is: With the above simple heuristic and a simple back tracing > of the CFG, all the > current testing cases for the following PRs passed without any issue: > > PR109071 > PR88771 > PR85788 > PR108770 > PR106762 > PR11

Re: [PATCH][RFC] phiopt: Optimize A < 0 ? ARG1 OP 2^n-1 : ARG1

On Fri, Jun 27, 2025, 11:06 AM Raphael Moreira Zinsly < rzin...@ventanamicro.com> wrote: > Hi all, > > For targets that have expensive shifts this may not get a better > sequence right now, specially for AVR and MSP430 according to > our tests. > Before I start looking for a fix on those targets I

Re: [PATCH][RFC] phiopt: Optimize A < 0 ? ARG1 OP 2^n-1 : ARG1

On Fri, Jun 27, 2025, 11:06 AM Raphael Moreira Zinsly < rzin...@ventanamicro.com> wrote: > Hi all, > > For targets that have expensive shifts this may not get a better > sequence right now, specially for AVR and MSP430 according to > our tests. > Before I start looking for a fix on those targets I

Re: [PATCH v2] tree-optimization/120780: Support object size for containing objects

On 2025-06-27 08:39, Siddhesh Poyarekar wrote: MEM_REF cast of a subobject to its containing object has negative offsets, which objsz sees as an invalid access. Support this use case by peeking into the structure to validate that the containing object indeed contains a type of the subobject at t

Re: [PATCH, V2, 1 of 3] Add -mcpu=future support.

Hi! On Wed, Jun 25, 2025 at 02:50:14PM -0400, Michael Meissner wrote: > This is patch #1 of 3 that adds the support that can be used in developing GCC > support for potential future PowerPC processors. With all 3 patches, the > tuning > for the 'future' processor is the same as power10 and power

Re: [PATCH][RFC] c/96570 - diagnostics for conversions to/from time_t

On Fri, 27 Jun 2025, Richard Biener wrote: > > I think such a warning should be based on an attribute on the time_t type > > that means "warn for implicit truncation of this type" (I'm less clear on > > why warnings for implicit widening conversions *to* time_t are supposed to > > be useful), r

RE: [PATCH V3] x86: Enable separate shrink wrapping

> -Original Message- > From: Cui, Lili > Sent: Friday, June 27, 2025 5:04 PM > To: H.J. Lu > Cc: ubiz...@gmail.com; gcc-patches@gcc.gnu.org; Liu, Hongtao > ; richard.guent...@gmail.com; Michael Matz > ; Sam James ; kenjin4...@gmail.com > Subject: RE: [PATCH

Re: [PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

On Fri, Jun 27, 2025 at 03:38:32PM +, Yuao Ma wrote: > Hi Jakub, > > > Please don't include math.h here. > > Done. > > > And instead of this line use __builtin_acospi (0.5). > > and, in dejagnu for runtime tests we prefer __builtin_abort on failure, so > > Done. Oh, one more thing. signbit

Re: [PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

On Fri, Jun 27, 2025 at 03:04:35PM +, Yuao Ma wrote: > > I think the __builtin_constant_p(acospi(0.5)) approach is usable, but would > > be much better done on the lib/target-supports.exp side. > > So, have foldable_pi_based_trigonometry effective target, which would test > > if __builtin_const

Re: [PATCH 7/8] libstdc++: Directly implement ranges::sample [PR100795]

On Fri, 27 Jun 2025 at 15:37, Patrick Palka wrote: > > On Fri, 27 Jun 2025, Jonathan Wakely wrote: > > > On 27/06/25 14:53 +0100, Jonathan Wakely wrote: > > > On 26/06/25 23:12 -0400, Patrick Palka wrote: > > > > On Thu, 26 Jun 2025, Patrick Palka wrote: > > > > > > > > > PR libstdc++/1007

Re: [PATCH 5/8] libstdc++: Directly implement ranges::stable_partition [PR100795]

On Fri, 27 Jun 2025 at 15:26, Patrick Palka wrote: > > On Fri, 27 Jun 2025, Jonathan Wakely wrote: > > > On 26/06/25 22:25 -0400, Patrick Palka wrote: > > > PR libstdc++/100795 > > > > > > libstdc++-v3/ChangeLog: > > > > > > * include/bits/ranges_algo.h (__detail::__find_if_not_n): New, >

Re: [PATCH 7/8] libstdc++: Directly implement ranges::sample [PR100795]

On Fri, 27 Jun 2025, Jonathan Wakely wrote: > On 27/06/25 14:53 +0100, Jonathan Wakely wrote: > > On 26/06/25 23:12 -0400, Patrick Palka wrote: > > > On Thu, 26 Jun 2025, Patrick Palka wrote: > > > > > > > PR libstdc++/100795 > > > > > > > > libstdc++-v3/ChangeLog: > > > > > > > >

Re: [PATCH 5/8] libstdc++: Directly implement ranges::stable_partition [PR100795]

On Fri, 27 Jun 2025, Jonathan Wakely wrote: > On 26/06/25 22:25 -0400, Patrick Palka wrote: > > PR libstdc++/100795 > > > > libstdc++-v3/ChangeLog: > > > > * include/bits/ranges_algo.h (__detail::__find_if_not_n): New, > > based on the stl_algo.h implementation. > > (__detail::__

Re: [PATCH] sh: Recognize >> 31 in treg_set_expr_not_const01

On 6/27/25 7:59 AM, Oleg Endo wrote: On Fri, 2025-06-27 at 10:51 -0300, Raphael Moreira Zinsly wrote: A right shift of 31 will become 0 or 1, this can be checked for treg_set_expr_not_const01 to avoid matching addc_t_r as this can expand to a 3 insn sequence instead. This improves tests 023

Re: [PATCH 4/8] libstdc++: Directly implement ranges::stable_sort [PR100795]

On Fri, 27 Jun 2025 at 15:16, Jonathan Wakely wrote: > > On Fri, 27 Jun 2025 at 15:15, Patrick Palka wrote: > > > > On Fri, 27 Jun 2025, Jonathan Wakely wrote: > > > > > On 26/06/25 22:25 -0400, Patrick Palka wrote: > > > > PR libstdc++/100795 > > > > > > > > libstdc++-v3/ChangeLog: > > > > >

Re: [PATCH 4/8] libstdc++: Directly implement ranges::stable_sort [PR100795]

On Fri, 27 Jun 2025 at 15:15, Patrick Palka wrote: > > On Fri, 27 Jun 2025, Jonathan Wakely wrote: > > > On 26/06/25 22:25 -0400, Patrick Palka wrote: > > > PR libstdc++/100795 > > > > > > libstdc++-v3/ChangeLog: > > > > > > * include/bits/ranges_algo.h (__detail::__move_merge): New, > > >

Re: [PATCH 4/8] libstdc++: Directly implement ranges::stable_sort [PR100795]

On Fri, 27 Jun 2025, Jonathan Wakely wrote: > On 26/06/25 22:25 -0400, Patrick Palka wrote: > > PR libstdc++/100795 > > > > libstdc++-v3/ChangeLog: > > > > * include/bits/ranges_algo.h (__detail::__move_merge): New, > > based on the stl_algo.h implementation. > > (__detail::__mer

Re: [PATCH 7/8] libstdc++: Directly implement ranges::sample [PR100795]

On 26/06/25 22:25 -0400, Patrick Palka wrote: PR libstdc++/100795 OK for trunk (the FIXME can stay for now and be dealt with later). libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__sample_fn::operator()): Reimplement the forward_iterator branch directly.

RE: [PATCH v2 0/4] RISC-V: Combine vec_duplicate + vssubu.vv to vssubu.vx on GR2VR cost

...@gmail.com; jeffreya...@gmail.com; Chen, Ken ; Liu, Hongtao ; Robin Dapp Subject: Re: [PATCH v2 0/4] RISC-V: Combine vec_duplicate + vssubu.vv to vssubu.vx on GR2VR cost > Is there anyway we can retrigger the test somewhere ? If no I can send a v3 > series with the commit reordered and s

Re: [PATCH 7/8] libstdc++: Directly implement ranges::sample [PR100795]

On 27/06/25 14:53 +0100, Jonathan Wakely wrote: On 26/06/25 23:12 -0400, Patrick Palka wrote: On Thu, 26 Jun 2025, Patrick Palka wrote: PR libstdc++/100795 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__sample_fn::operator()): Reimplement the forward_iterator

Re: [PATCH v2 0/4] RISC-V: Combine vec_duplicate + vssubu.vv to vssubu.vx on GR2VR cost

Is there anyway we can retrigger the test somewhere ? If no I can send a v3 series with the commit reordered and see. I don't think there's a way other than re-submitting. But if you're sure you tested properly and the CI is mistaken we can go ahead. I just wanted to make sure as with the s

Re: [PATCH] sh: Recognize >> 31 in treg_set_expr_not_const01

On Fri, 2025-06-27 at 10:51 -0300, Raphael Moreira Zinsly wrote: > A right shift of 31 will become 0 or 1, this can be checked for > treg_set_expr_not_const01 to avoid matching addc_t_r as this > can expand to a 3 insn sequence instead. > This improves tests 023 to 026 from gcc.target/sh/pr54236-

Re: [PATCH 8/8] libstdc++: Directly implement ranges::shuffle [PR100795]

On 26/06/25 22:25 -0400, Patrick Palka wrote: PR libstdc++/100795 OK for trunk. libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (shuffle_fn::operator()): Reimplement directly. * testsuite/25_algorithms/shuffle/constrained.cc (test02): --- libstdc++-v3/in

Re: [PATCH v2 0/4] RISC-V: Combine vec_duplicate + vssubu.vv to vssubu.vx on GR2VR cost

OK. Hmm, I'm still seeing test failures in the CI. Could you check if those are valid? -- Regards Robin

Re: [PATCH 7/8] libstdc++: Directly implement ranges::sample [PR100795]

On 26/06/25 23:12 -0400, Patrick Palka wrote: On Thu, 26 Jun 2025, Patrick Palka wrote: PR libstdc++/100795 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__sample_fn::operator()): Reimplement the forward_iterator branch directly. * testsuite/25_algorith

Re: [PATCH 1/2] allow contraction to synthetic single-element vector FMA

On Fri, 27 Jun 2025, Richard Biener wrote: > > I am testing partial fixes for these issues. > > Can you check again after r16-1731-g08bdb6b4a32f1f? Certainly. There's no more fmaddsub-related testsuite failures, and only three tests need adjustment on x86. * gcc.target/i386/pr116979.c Here

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,PR1

Hi, A status update on this patch: (Actually a good news!) > On Jun 10, 2025, at 11:32, Qing Zhao wrote: > > > >>> >>> It's difficult to do any meaningful pruning I think. Consider >>> >>> if (i == -1) >>> tem = a[i]; >>> >>> when we transform this to >>> >>> if (i == -1) >>> t

Re: [PATCH 6/8] libstdc++: Directly implement ranges::nth_element [PR100795]

On 26/06/25 22:25 -0400, Patrick Palka wrote: PR libstdc++/100795 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__detail::__introselect): New, based on the stl_algo.h implementation. (nth_element_fn::operator()): Reimplement in terms of the above.

Re: [PATCH 5/8] libstdc++: Directly implement ranges::stable_partition [PR100795]

On 26/06/25 22:25 -0400, Patrick Palka wrote: PR libstdc++/100795 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__detail::__find_if_not_n): New, based on the stl_algo.h implementation. (__detail::__stable_partition_adaptive): Likewise. (__stable_p

Re: [PATCH 5/8] libstdc++: Directly implement ranges::stable_partition [PR100795]

On 26/06/25 22:25 -0400, Patrick Palka wrote: PR libstdc++/100795 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__detail::__find_if_not_n): New, based on the stl_algo.h implementation. (__detail::__stable_partition_adaptive): Likewise. (__stable_p

RE: [PATCH v2 0/4] RISC-V: Combine vec_duplicate + vssubu.vv to vssubu.vx on GR2VR cost

Message- From: Robin Dapp Sent: Friday, June 27, 2025 9:08 PM To: Robin Dapp ; Li, Pan2 ; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; Chen, Ken ; Liu, Hongtao ; Robin Dapp Subject: Re: [PATCH v2 0/4] RISC-V: Combine vec_duplicate + vssubu.vv to

Re: [patch,avr] Turn on LRA per default

On 6/27/25 7:08 AM, Georg-Johann Lay wrote: This turns on -mlra per default on avr. Ok for trunk? Yes, definitely. The more soak time it gets the better IMHO. jeff

Re: [PATCH 4/8] libstdc++: Directly implement ranges::stable_sort [PR100795]

On 26/06/25 22:25 -0400, Patrick Palka wrote: PR libstdc++/100795 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__detail::__move_merge): New, based on the stl_algo.h implementation. (__detail::__merge_sort_loop): Likewise. (__detail::__chunk_inser

Re: [PATCH] tree-optimization/120780: Support object size for containing objects

On 2025-06-27 08:05, Jakub Jelinek wrote: On Fri, Jun 27, 2025 at 02:00:26PM +0200, Richard Biener wrote: + gcc_assert (RECORD_OR_UNION_TYPE_P (container)); + + for (tree t = TYPE_FIELDS (container); t; t = DECL_CHAIN (t)) +{ + if (TREE_CODE (t) != FIELD_DECL) +continue; + +

Re: [PATCH 3/8] libstdc++: Directly implement ranges::inplace_merge [PR100795]

On 26/06/25 22:25 -0400, Patrick Palka wrote: As with the previous patch, this patch reimplements ranges::inplace_merge directly instead of incorrectly forwarding to std::inplace_merge. In addition to the compatibility changes listed in the previous patch we also: - explicitly cast the differe

Re: [PATCH 2/8] libstdc++: Directly implement ranges::sort [PR100795]

On 26/06/25 22:25 -0400, Patrick Palka wrote: As with the previous patch, this patch reimplements ranges::sort directly instead of incorrectly forwarding to std::sort. In addition to the compatibility changes listed in the previous patch we also: - use ranges::iter_swap instead of std::iter_sw

Re: [PATCH 1/8] libstdc++: Directly implement ranges::heap algos [PR100795]

On 26/06/25 22:25 -0400, Patrick Palka wrote: ranges::push_heap, ranges::pop_heap, ranges::make_heap and ranges::sort_heap are currently defined in terms of the corresponding STL-style algorithms, but this is incorrect because the STL-style algorithms rely on the legacy iterator system, and so mi

Re: [PATCH] match: Unwrap non-lvalue as unary or binary operand

Le 23/06/2025 à 09:34, Richard Biener a écrit : On Sun, Jun 22, 2025 at 10:23 PM Mikael Morin wrote: From: Mikael Morin See the description in the ChangeLog entry below. The testcases are best effort; for some operators the fortran frontend generates a temporary variable, so the simplificat

Re: [PATCH] libstdc++: Fix warnings introduced by type-erasing for chrono commits [PR110739]

On 27/06/25 13:01 +0200, Tomasz Kamiński wrote: The r16-1709-g4b3cefed1a08344495fedec4982d85168bd8173f caused `-Woverflow` in empty_spec.cc file. This warning is not cause by any issue in shipping code, and results in taking to much shorcut when implementing a test-only custom representation type

Re: [PATCH] tree-optimization/120780: Support object size for containing objects

On Fri, Jun 27, 2025 at 02:00:26PM +0200, Richard Biener wrote: > > + gcc_assert (RECORD_OR_UNION_TYPE_P (container)); > > + > > + for (tree t = TYPE_FIELDS (container); t; t = DECL_CHAIN (t)) > > +{ > > + if (TREE_CODE (t) != FIELD_DECL) > > +continue; > > + > > + tree byte_off

Re: [PATCH] tree-optimization/120780: Support object size for containing objects

> Am 27.06.2025 um 13:40 schrieb Siddhesh Poyarekar : > > MEM_REF cast of a subobject to its containing object has negative > offsets, which objsz sees as an invalid access. Support this use case > by peeking into the structure to validate that the containing object > indeed contains a type o

Re: [PATCH] libstdc++: Use runtime format for internal format calls in chrono [PR110739]

On Fri, Jun 27, 2025 at 11:23 AM Jonathan Wakely wrote: > On Fri, 27 Jun 2025 at 10:10, Tomasz Kaminski wrote: > > > > > > > > On Fri, Jun 27, 2025 at 10:31 AM Tomasz Kamiński > wrote: > >> > >> This patch adjust all internal std::format call inside of > __formatter_chrono, > >> to use runtime

Re: [PATCH] tree-optimization/120780: Support object size for containing objects

On 2025-06-27 07:40, Siddhesh Poyarekar wrote: MEM_REF cast of a subobject to its containing object has negative offsets, which objsz sees as an invalid access. Support this use case by peeking into the structure to validate that the containing object indeed contains a type of the subobject at t

Re: [PATCH v4 1/1] libstdc++: Implement default_accessor from mdspan.

On 6/27/25 11:44, Jonathan Wakely wrote: On Fri, 27 Jun 2025 at 10:39, Tomasz Kaminski wrote: Also, for single patch (not-patch series), you do not need to have [PATCH 0/N], simple [PATCH] and then [PATCH v2] also works. Yeah, sending a 0/N cover letter is only useful to describe what a

Re: [PATCH v5] libstdc++: Implement default_accessor from mdspan.

Sorry, I'll continue working another day. This commit is broken; please ignore. On 6/27/25 13:15, Luc Grosheintz wrote: libstdc++-v3/ChangeLog: * include/std/mdspan (default_accessor): New class. * src/c++23/std.cc.in: Register default_accessor. * testsuite/23_containers

Re: [PATCH] libstdc++: Fix warnings introduced by type-erasing for chrono commits [PR110739]

On Fri, Jun 27, 2025 at 1:03 PM Tomasz Kamiński wrote: > The r16-1709-g4b3cefed1a08344495fedec4982d85168bd8173f caused `-Woverflow` > in empty_spec.cc file. This warning is not cause by any issue in shipping > code, and results in taking to much shorcut when implementing a test-only > custom repr

Re: [PATCH 1/2] allow contraction to synthetic single-element vector FMA

On Wed, Jun 25, 2025 at 11:39 AM Richard Biener wrote: > > On Tue, Jun 24, 2025 at 5:25 PM Alexander Monakov wrote: > > > > > I'd say we want to fix these kind of things before switching the default. > > > Can > > > you file bugreports for the distinct issues you noticed when adjusting the > >

Re: [PATCH] [RFC] RISC-V: Add extra check to help choosing multilib with equivalent arch.

> From:Kito Cheng > Send Time:2025 Jun. 9 (Mon.) 17:33 > To:yunzezhu > CC:"gcc-patches" > Subject:Re: [PATCH] [RFC] RISC-V: Add extra check to help choosing multilib > with equivalent arch. > > > Oh, yeah, I got your point, I was just misreading, the march is > rv32imac rather than rv32imafc, t

Re: [PATCH] libstdc++: Use runtime format for internal format calls in chrono [PR110739]

On Fri, 27 Jun 2025 at 11:01, Tomasz Kaminski wrote: > > > > On Fri, Jun 27, 2025 at 11:23 AM Jonathan Wakely wrote: >> >> On Fri, 27 Jun 2025 at 10:10, Tomasz Kaminski wrote: >> > >> > >> > >> > On Fri, Jun 27, 2025 at 10:31 AM Tomasz Kamiński >> > wrote: >> >> >> >> This patch adjust all int

Re: [PATCH] libstdc++: Use runtime format for internal format calls in chrono [PR110739]

On Fri, Jun 27, 2025 at 11:23 AM Jonathan Wakely wrote: > On Fri, 27 Jun 2025 at 10:10, Tomasz Kaminski wrote: > > > > > > > > On Fri, Jun 27, 2025 at 10:31 AM Tomasz Kamiński > wrote: > >> > >> This patch adjust all internal std::format call inside of > __formatter_chrono, > >> to use runtime

Re: [PATCH] libstdc++: Use runtime format for internal format calls in chrono [PR110739]

On Fri, 27 Jun 2025 at 10:10, Tomasz Kaminski wrote: > > > > On Fri, Jun 27, 2025 at 10:31 AM Tomasz Kamiński wrote: >> >> This patch adjust all internal std::format call inside of __formatter_chrono, >> to use runtime format stirng and thus avoid compile time checking of validity >> of the forma

Re: [PATCH v4 1/1] libstdc++: Implement default_accessor from mdspan.

On Fri, 27 Jun 2025 at 10:39, Tomasz Kaminski wrote: > > Also, for single patch (not-patch series), you do not need to have [PATCH > 0/N], simple [PATCH] and then [PATCH v2] also works. Yeah, sending a 0/N cover letter is only useful to describe what a multi-part patch series does. For a single

Re: [PATCH v4 1/1] libstdc++: Implement default_accessor from mdspan.

Also, for single patch (not-patch series), you do not need to have [PATCH 0/N], simple [PATCH] and then [PATCH v2] also works. On Fri, Jun 27, 2025 at 11:11 AM Tomasz Kaminski wrote: > > > On Fri, Jun 27, 2025 at 11:06 AM Luc Grosheintz > wrote: > >> libstdc++-v3/ChangeLog: >> >> * incl

  1   2   3   4   5   6   7   8   9   10   >