[committed v3 3/4] libstdc++: Format empty chrono-spec for the sys_info and local_info directly.

This patch change implementation of the formatters for sys_info and local_info, so they no longer delegate to operator<< for ostream in case of empty spec. As this types may be only formatted with chrono-spec containing only %%, %t, %n specifiers and fill characters, we use a separate __formatter_c

[committed v2] libstdc++: Test chrono-spec containing only whitespaces.

libstdc++-v3/ChangeLog: * testsuite/std/time/format/whitespace.cc: New test. Reviewed-by: Jonathan Wakely Signed-off-by: Tomasz Kamiński --- v2 adds missing _GLIBCXX_USE_CXX11_ABI check for uses of sys_info/local_info. Tested on x86_64-linux. Pushed to trunk. .../testsuite/std/time/fo

[PATCH 0/1] [RFC][AutoFDO] Propagate inline information to outline definitions if not inlined

From: Dhruv Chawla For reasons explained in the patch, this patch prevents the loss of profile information when inlining occurs in the profiled binary but not in the auto-profile pass as a decision. As an example, for this code: #define TRIP 10 #ifdef DO_NOINLINE # define INLINE __attri

Re: FW: [PATCH] gcc: Make int n_infiles local to gcc.cc.

On Thu, Jun 12, 2025 at 09:21:38PM -0500, Robert Dubner wrote: > It occurs to me that with 500 or so messages a day coming through, perhaps > targeting individuals might be useful. > > Consider this somewhere between an initial message and a ping: > > -Original Message- > From: Robert Dub

[PATCH] libsanitizer: Fix 'unknown-crash' reported for partial buffer overflows

Given a partially misaligned memory read for a large number of bytes (e.g., we allocate data at addr [0, 16) but read addr [2, 18)), the address sanitizer (asan) would flag the error as an 'unknown-crash' instead of a 'stack-buffer-overflow' when compiled with gcc. This is due to a flawed heuristi

[gcc-wwwdocs PATCH] gcc-15: Correct DMR ISA base platform to include AMX-COMPLEX

Hi all, I just found that since AMX-COMPLEX is enabled on Diamond Rapids but not enabled on Granite Rapids, we should use the ISA level from Granite Rapids D instead of Granite Rapids to show that. Since Diamond Rapids is the actual successor of Granite Rapids but not Granite Rapids D, I slightly

Re: [PATCH] driver: Try to read spec from gcc_exec_prefix if possible

Thanks, pushed to trunk :) On Fri, Jun 13, 2025 at 4:18 AM Joseph Myers wrote: > > On Tue, 10 Jun 2025, Kito Cheng wrote: > > > GCC will try to read the spec file from the directory where it is > > installed, but it should try to read from gcc_exec_prefix rather than > > standard_exec_prefix, bec

Re: [PATCH] libstdc++: Optimize __make_comp_proj and __make_pred_proj for empty types

On Thu, Jun 12, 2025 at 9:05 PM Patrick Palka wrote: > On Thu, 12 Jun 2025, Patrick Palka wrote: > > > On Thu, 12 Jun 2025, Jonathan Wakely wrote: > > > > > > > > > > > On Thu, 12 Jun 2025, 16:56 Patrick Palka, wrote: > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > >

Re: [PATCH v2 3/4] libstdc++: Format empty chrono-spec for the sys_info and local_info directly.

On Thu, Jun 12, 2025 at 5:50 PM Jonathan Wakely wrote: > > > On Thu, 12 Jun 2025, 16:19 Tomasz Kamiński, wrote: > >> This patch change implementation of the formatters for sys_info and >> local_info, >> so they no longer delegate to operator<< for ostream in case of empty >> spec. >> As this typ

[PATCH v2 x86: Extend the remove_redundant_vector pass

On Mon, Jun 9, 2025 at 2:42 PM Hongtao Liu wrote: > > On Tue, Jun 3, 2025 at 2:59 PM H.J. Lu wrote: > > > > Extend the remove_redundant_vector pass to handle vector broadcasts from > > constant and variable scalars. When broadcasting from constants and > > function arguments, we can place a sing

FW: [PATCH] gcc: Make int n_infiles local to gcc.cc.

It occurs to me that with 500 or so messages a day coming through, perhaps targeting individuals might be useful. Consider this somewhere between an initial message and a ping: -Original Message- From: Robert Dubner Sent: Monday, June 9, 2025 19:19 To: gcc-patches@gcc.gnu.org Subject: [

Re: [PATCH] emit-rtl: Use simplify_subreg_regno to validate hardware subregs [PR119966]

On 6/12/25 12:27 PM, Dimitar Dimitrov wrote: ./../../..//gcc/libgcc/libgcc2.c: In function '__ucmpdi2': ../../../..//gcc/libgcc/libgcc2.c:2060:1: internal compiler error: in update_reg_eliminate, at lra-eliminations.cc:1200 It's not so bad now. I just tested with today's trunk r16-1485-g8f

Libang Precision Mold Factory of China

Dongguan Libang Precision Mold Co.,Ltd Cellphone/Wechat/Skype/What'sapp: +86 134 5066 5737 Address: The 3rd Floor,Building 2,No.13,Hexin Street,Shatou Community,Chang'an Town, Dongguan City,Guangdong Province,China.523861

RE: [r16-1429 Regression] FAIL: g++.target/i386/vect-pragma-target-2.C -std=gnu++98 (test for excess errors) on Linux/x86_64

I will do that. Thx, Haochen From: Andrew Pinski Sent: Thursday, June 12, 2025 10:52 PM Cc: gb.de...@gmail.com; gcc-regress...@gcc.gnu.org; GCC Patches ; Jiang, Haochen Subject: Re: [r16-1429 Regression] FAIL: g++.target/i386/vect-pragma-target-2.C -std=gnu++98 (test for excess errors) on Lin

Re: [PATCH] mcore: Don't use gen_rtx_MEM on __attribute__((dllimport))

On 6/12/25 4:03 PM, H.J. Lu wrote: PR target/120589 * config/mcore/mcore.cc (mcore_mark_dllimport): Don't use gen_rtx_MEM. Biggest concern here would be the interaction with the call expanders, but I think that's OK from a quick looksie. As I noted to HJ (probably privately) this patch wa

[PATCH] mcore: Don't use gen_rtx_MEM on __attribute__((dllimport))

On mcore-elf, mcore_mark_dllimport generated (gdb) call debug_tree (decl) > HI size unit-size align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fff e981f000 arg-types > pointer_to_this > addressable used public external decl

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

Ping On 21/05/2025 16:13, Christopher Bazley wrote: 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

New Spanish PO file for 'gcc' (version 15.1.0)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Spanish team of translators. The file is available at: https://translationproject.org/latest/gcc/es.po (This file, 'gcc-15.1.0.es.po', has ju

Re: [PATCH] driver: Try to read spec from gcc_exec_prefix if possible

On Tue, 10 Jun 2025, Kito Cheng wrote: > GCC will try to read the spec file from the directory where it is > installed, but it should try to read from gcc_exec_prefix rather than > standard_exec_prefix, because the latter is not the right one if > compiler has been relocated into other places othe

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

Hi Steve, On 6/11/25 23:06, Steve Kargl wrote: On Wed, Jun 11, 2025 at 10:18:37PM +0200, Harald Anlauf wrote: - for the INTEGER(KIND=4) versions the STATUS returns ERANGE if an overflow is encountered. The latter is certainly debatable, as one of the existing testcases stat_{1,2}.f90 may fa

Re: [wwwdocs] Add C2y status table

On Thu, 12 Jun 2025, Marek Polacek wrote: > + > + > +Support ++ and -- on complex values > + href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3259.pdf";>N3259 > +15 > + > + This should be when the feature was supported (either GCC 2.5 when complex types were introd

Re: [PATCH] libstdc++: Optimize __make_comp_proj and __make_pred_proj for empty types

On Thu, 12 Jun 2025, Patrick Palka wrote: > On Thu, 12 Jun 2025, Jonathan Wakely wrote: > > > > > > > On Thu, 12 Jun 2025, 16:56 Patrick Palka, wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > > > I'm sure if introducing a new overload is preferable to >

Re: [PATCH v4 1/3][C FE]Extend "counted_by" attribute to pointer fields of structures.

> On Jun 12, 2025, at 14:32, Joseph Myers wrote: > > On Thu, 12 Jun 2025, Qing Zhao wrote: > >>> In general I think we'd only expect an error if the information required >>> to give it is visible at the point where the counted_by attribute is used. >>> There might be a possibility of giving

Re: [PATCH v4 1/3][C FE]Extend "counted_by" attribute to pointer fields of structures.

On Thu, 12 Jun 2025, Qing Zhao wrote: > > In general I think we'd only expect an error if the information required > > to give it is visible at the point where the counted_by attribute is used. > > There might be a possibility of giving an error for this case when the > > pointer gets derefere

Re: [PATCH] emit-rtl: Use simplify_subreg_regno to validate hardware subregs [PR119966]

On Thu, Jun 12, 2025 at 08:12:59AM -0600, Jeff Law wrote: > > > On 6/12/25 4:04 AM, Richard Sandiford wrote: > > > > > Richard, Jeff, it does not seem appropriate to merge this patch now, > > > > given that it breaks avr and or1k. Let me know if such experiment is > > > > desired despite the kn

Re: [PATCH v4 1/3][C FE]Extend "counted_by" attribute to pointer fields of structures.

Based on all your comments so far, I changed the documentation as the following: -The counted_by attribute is not allowed for a pointer field whose pointee -has type @code{void}. +The counted_by attribute is not allowed for a pointer to @code{void}, +a pointer to function, or a pointer to a struct

[PATCH] expand: Fix up edge splitting for ENTRY block during expansion if there are any PHIs [PR120629]

Hi! Andrew ran some extra ranger checking during bootstrap and found one more case (though much rarer than the GIMPLE_COND case). Seems on fold-const.cc (native_encode_expr) we end up with bb 2, ENTRY bb successor, having PHI nodes (usually there is some bb in between, even if empty, in the nativ

Re: [PATCH] recip: Reset range info when replacing sqrt with rsqrt [PR120638]

On 6/12/25 11:41 AM, Jakub Jelinek wrote: Hi! This pass reuses a SSA_NAME on the lhs of sqrt etc. call as lhs of .RSQRT etc. call. The following testcase is miscompiled since my recent ranger cast changes, because we compute (correct) range for sqrtf argument as well as result but then recip

[committed] testsuite: Add testcase for already fixed PR [PR120630]

Hi! These tests were broken by my r16-1398 PR120434 change and fixed by r16-1482 PR120629 change. Committing these to increase testsuite coverage. 2025-06-12 Jakub Jelinek PR middle-end/120630 * gcc.dg/pr120630.c: New test. * gcc.c-torture/execute/pr120630.c: New test

[PATCH] tailc: Allow musttail tail calls with -fsanitize=address [PR120608]

Hi! These testcases show another problem with -fsanitize=address vs. musttail tail calls. In particular, there can be .ASAN_MARK (POISON, &a, 4); etc. calls after a tail call and those just prevent the tailc pass to mark the musttail calls as [tail call]. Normally, the sanopt pass (which comes

[PATCH] recip: Reset range info when replacing sqrt with rsqrt [PR120638]

Hi! This pass reuses a SSA_NAME on the lhs of sqrt etc. call as lhs of .RSQRT etc. call. The following testcase is miscompiled since my recent ranger cast changes, because we compute (correct) range for sqrtf argument as well as result but then recip pass keeps using that range for the .RQSRT cal

Re: [wwwdocs] Add C23 status table

On Wed, 11 Jun 2025, Marek Polacek wrote: > This patch adds the C23 Support in GCC table (compiler features only). > > While creating it, I've consulted Annex M.2, our own changes.html, > Joseph's "ISO C23 support in the GNU Toolchain" Cauldron presentation, > https://en.cppreference.com/w/c/comp

[PATCH] expand: Allow musttail tail calls with -fsanitize=address [PR120608]

Hi! The following testcase is rejected by GCC 15 but accepted (with s/gnu/clang/) by clang. The problem is that we want to execute a sequence of instructions to unpoison all automatic variables in the function and mark the var block allocated for use-after-return sanitization poisoned after the ca

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

On Thu, 12 Jun 2025, Patrick Palka wrote: > Changes in v4: > * Don't pass a projection function throughout the helpers, instead > create a pass a composite predicate via __make_comp_proj. > > -- >8 -- > > ranges::push_heap, ranges::pop_heap, ranges::make_heap and > ranges::sort_heap are cu

Re: [wwwdocs] Add C2y status table

On Thu, Jun 12, 2025 at 06:59:02PM +0200, Jakub Jelinek wrote: > On Thu, Jun 12, 2025 at 12:50:00PM -0400, Marek Polacek wrote: > > + > > + > > +More Modern Bit Utilities > > + > href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3367.htm";>N3367 > > + > > +15 > > I thin

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

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 (duplicate_decls): Change logic to not always exclude F

[PATCH v6 19/19] FMV: Redirect to specific target

Adds an optimisation in FMV to redirect to a specific target if possible. A call is redirected to a specific target if both: - the caller can always call the callee version - and, it is possible to rule out all higher priority versions of the callee fmv set. That is estabilished either by the ca

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

On Thu, 12 Jun 2025, Patrick Palka wrote: > Changes in v4: > * Don't pass a projection function throughout the helpers, instead > create a pass a composite predicate via __make_comp_proj. > > -- >8 -- > > As with the previous patch, this patch reimplements ranges::sort > directly instead o

Re: [PATCH] libstdc++: Optimize __make_comp_proj and __make_pred_proj for empty types

On Thu, 12 Jun 2025, Jonathan Wakely wrote: > > > On Thu, 12 Jun 2025, 16:56 Patrick Palka, wrote: > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > I'm sure if introducing a new overload is preferable to > introducing a constexpr if branch in the existing ove

[PATCH v6 17/19] c: Add target_version attribute support.

This commit introduces support for the target_version attribute in the c frontend, following the behavior defined in the Arm C Language Extension. Key changes include: - During pushdecl, the compiler now checks whether the current symbol is part of a multiversioned set. - New versions are add

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

On Thu, 12 Jun 2025, Patrick Palka wrote: > On Thu, 12 Jun 2025, Patrick Palka wrote: > > > On Thu, 12 Jun 2025, Tomasz Kaminski wrote: > > > > > > > > > > > > > > On Thu, Jun 12, 2025 at 5:06 PM Patrick Palka wrote: > > > On Wed, 11 Jun 2025, Tomasz Kaminski wrote: > > > > > >

[PATCH v6 18/19] c/aarch64: Add FMV diagnostic tests.

Adds some aarch64 C fmv diagnostic tests. This mostly tests C front end code, but has to be target specific at FMV is requires specifying target extensions. gcc/testsuite/ChangeLog: * gcc.target/aarch64/mv-and-mvc-error1.c: New test. * gcc.target/aarch64/mv-and-mvc-error2.c: New

[PATCH v6 12/19] c++: Refactor FMV frontend conflict and merging logic and hooks.

This change refactors FMV handling in the frontend to allows greater reasoning about versions in shared code. This is needed for allowing target_clones and target_versions to be used together in a function set, as there is then two distinct concerns when encountering two declarations that previous

[PATCH v6 16/19] aarch64: Remove FMV beta warning.

This patch removes the warning for target_version and target_clones in aarch64 as it is now spec compliant. gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_process_target_version_attr): Remove warning. * config/aarch64/aarch64.opt: Mark -Wno-experimental-fmv-target

[PATCH v6 15/19] aarch64: testsuite: Add diagnostic tests for Aarch64 FMV.

Add tests covering many FMV errors for Aarch64, including redeclaration, and mixing target_clones and target_versions. gcc/testsuite/ChangeLog: * g++.target/aarch64/mv-and-mvc-error1.C: New test. * g++.target/aarch64/mv-and-mvc-error2.C: New test. * g++.target/aarch64/mv-a

Re: [wwwdocs] Add C2y status table

On Thu, Jun 12, 2025 at 12:50:00PM -0400, Marek Polacek wrote: > + > + > +More Modern Bit Utilities > + href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3367.htm";>N3367 > + > +15 I think everything that needs compiler support is in GCC 15, but it is mostly a library t

[PATCH v6 10/19] fmv: Change target_version semantics to follow ACLE specification.

This patch changes the semantics of target_version and target_clones attributes to match the behavior described in the Arm C Language extension. The changes to behavior are: - The scope and signature of an FMV function set is now that of the default version. - The FMV resolver is now created at

[PATCH] config/arm/arm.cc thumbv1 fixes - Patch for bugzilla tickets 117366 and 117468

This can replace my earlier e-mail which addressed only ticket 117366. Since both the bugs are in one file and somewhat related, here's a larger patch that address both bugzilla tickets 117366 and 117468 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117468): index bde06f3fa86..742b0904612

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

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. After this change diagnostics look like: ```

[PATCH v6 04/19] Add get_clone_versions and get_target_version functions.

Note: Approved by Jeff Law, waiting on string_slice. -- >8 -- This is a reimplementation of get_target_clone_attr_len, get_attr_str, and separate_attrs using string_slice and auto_vec to make memory management and use simpler. Adds get_target_version helper function to get the target_version str

[PATCH v6 06/19] Add clone_identifier function.

Note: Approved by Jeff Law, waiting on string_slice. -- >8 -- This is similar to clone_function_name and its siblings but takes an identifier tree node rather than a function declaration. This is to be used in conjunction with the identifier node stored in cgraph_function_version_info::assembler

[PATCH v6 13/19] fmv: Support mixing of target_clones and target_version.

Add support for a FMV set defined by a combination of target_clones and target_version definitions. Additionally, change is_function_default_version to consider a function declaration annotated with target_clones containing default to be a default version. Lastly, add support for the case that a

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

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 Arm C Language Extension. The purpose of this is

[PATCH v6 07/19] fmv: Refactor FMV name mangling.

This patch is an overhaul of how FMV name mangling works. Previously mangling logic was duplicated in several places across both target specific and independent code. This patch changes this such that all mangling is done in targetm.mangle_decl_assembler_name (including for the dispatched symbol an

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

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 the front end. This refactor primarily serves jus

[PATCH v6 02/19] Remove unnecessary `record` argument from maybe_version_functions.

Previously, the `record` argument in maybe_version_function allowed the call to cgraph_node::record_function_versions to be skipped. However, this was only skipped when both decls were already marked as versioned, in which case we trigger the early exit in record_function_versions instead. Therefo

[PATCH v6 03/19] Change make_attribute to take string_slice.

Note: Approved by Jeff Law, waiting on string_slice. -- >8 -- gcc/ChangeLog: * attribs.cc (make_attribute): Change arguments. * attribs.h (make_attribute): Change arguments. Approved by Richard Sandiford. --- gcc/attribs.cc | 16 +--- gcc/attribs.h | 2 +- 2 files

[PATCH v6 05/19] Add dispatcher_resolver_function and is_target_clone flags to cgraph_node.

Note: Approved by Jeff Law, waiting on patches that make use of these. -- >8 -- These are needed to correctly mangle FMV declarations. gcc/ChangeLog: * cgraph.h (struct cgraph_node): Add dispatcher_resolver_function and is_target_clone. --- gcc/cgraph.h | 10 +- 1 file

[PATCH v6 01/19] Add string_slice class.

The string_slice inherits from array_slice and is used to refer to a substring of an array that is memory managed elsewhere without modifying the underlying array. For example, this is useful in cases such as when needing to refer to a substring of an attribute in the syntax tree. Adds some minim

[PATCH v6 00/19] FMV refactor, C FMV support and ACLE compliance.

Hi All, Small update to remove committed patches, and merge two patches to make them atomic. Note this series includes several approved, but not yet committed, patches. This is either because they depend on other patches or because it seems strange to commit class members without any usage. Appro

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

Changes in v4: * Don't pass a projection function throughout the helpers, instead create a pass a composite predicate via __make_comp_proj. -- >8 -- As with the previous patch, this patch reimplements ranges::sort directly instead of incorrectly forwarding to std::sort. In addition to the

[wwwdocs] Add C2y status table

To be applied on top of the C23 status table patch. W3 validated. Ok? -- >8 -- diff --git a/htdocs/projects/c-status.html b/htdocs/projects/c-status.html index 7e522bc3..5bee3e25 100644 --- a/htdocs/projects/c-status.html +++ b/htdocs/projects/c-status.html @@ -31,7 +31,6 @@ GCC has experimenta

[PATCH v4 1/2] libstdc++: Directly implement ranges::heap algos [PR100795]

Changes in v4: * Don't pass a projection function throughout the helpers, instead create a pass a composite predicate via __make_comp_proj. -- >8 -- ranges::push_heap, ranges::pop_heap, ranges::make_heap and ranges::sort_heap are currently defined in terms of the corresponding STL-style alg

Re: [committed] [PATCH] libstdc++: add range support to std::optional (P3168)

Hello, On 12/06/2025 13:09, Jonathan Wakely wrote: Reviewed and approved on the forge - thanks. Thank you. I've committed it as r16-1487-g774ae8734f0e19, also attached. Cheers, -- Giuseppe D'Angelo From 774ae8734f0e199a8c6d29dd8c186b893385470b Mon Sep 17 00:00:00 2001 From: Giuseppe D'Angelo

Re: [committed] [PATCH] libstdc++: do not use an unreserved name in _Temporary_buffer [PR119496]

Hi, On 05/06/2025 23:22, Giuseppe D'Angelo wrote: Thanks for the quick review! I've pushed a new version on Forge. Patch was iterated upon on Forge and approved there. Committed as r16-1488-gc9a6c1b5a763d0 and attached. Cheers, -- Giuseppe D'Angelo From c9a6c1b5a763d0d3f7a369ed281f9009f270939

Re: [PATCH] AArch64 SIMD: convert mvn+shrn into mvni+subhn

On 6/12/25 12:02, Richard Sandiford wrote: > External email: Use caution opening links or attachments > > > Remi Machet writes: >> Add an optimization to aarch64 SIMD converting mvn+shrn into mvni+subhn >> which >> allows for better optimization when the code is inside a loop by using a >> consta

Re: [PATCH] AArch64 SIMD: convert mvn+shrn into mvni+subhn

> On 12 Jun 2025, at 18:20, Remi Machet wrote: > > > On 6/12/25 12:02, Richard Sandiford wrote: >> External email: Use caution opening links or attachments >> >> >> Remi Machet writes: >>> Add an optimization to aarch64 SIMD converting mvn+shrn into mvni+subhn >>> which >>> allows for bett

Re: [PATCH] or1k: Fix ICE in libgcc caused by recent validate_subreg changes

On Mon, Jun 09, 2025 at 07:59:46PM +0100, Stafford Horne wrote: > After commit eb2ea476db2 ("emit-rtl: Allow extra checks for > paradoxical subregs [PR119966]") paradoxical subregs or the OpenRISC > condition flag register (reg:BI sr_f) are no longer allowed. > > This causes and ICE in the ce1 pas

Re: [PATCH] AArch64 SIMD: convert mvn+shrn into mvni+subhn

> On 12 Jun 2025, at 18:02, Richard Sandiford wrote: > > Remi Machet writes: >> Add an optimization to aarch64 SIMD converting mvn+shrn into mvni+subhn >> which >> allows for better optimization when the code is inside a loop by using a >> constant. >> >> Bootstrapped and regtested on aarch6

Re: [PATCH] libstdc++: Optimize __make_comp_proj and __make_pred_proj for empty types

On Thu, 12 Jun 2025, 16:56 Patrick Palka, wrote: > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > I'm sure if introducing a new overload is preferable to > introducing a constexpr if branch in the existing overload. > I think a constexpr if branch in the existing functions is ch

Re: [PATCH] AArch64 SIMD: convert mvn+shrn into mvni+subhn

Remi Machet writes: > Add an optimization to aarch64 SIMD converting mvn+shrn into mvni+subhn > which > allows for better optimization when the code is inside a loop by using a > constant. > > Bootstrapped and regtested on aarch64-linux-gnu. > > Signed-off-by: Remi Machet > > gcc/ChangeLog: > >

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

On Thu, 12 Jun 2025, Patrick Palka wrote: > On Thu, 12 Jun 2025, Tomasz Kaminski wrote: > > > > > > > > > On Thu, Jun 12, 2025 at 5:06 PM Patrick Palka wrote: > > On Wed, 11 Jun 2025, Tomasz Kaminski wrote: > > > > > > > > > > > On Tue, Jun 10, 2025 at 3:08 AM Patrick

[PATCH] libstdc++: Optimize __make_comp_proj and __make_pred_proj for empty types

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? I'm sure if introducing a new overload is preferable to introducing a constexpr if branch in the existing overload. -- >8 -- When composing a comparator/predicate and projection function, if both are stateless (and default constructible

Re: [PATCH v2 4/4] libstdc++: Rework formatting of empty chrono-spec for duration.

On Thu, 12 Jun 2025, 16:24 Tomasz Kamiński, wrote: > In contrast to other calendar types if empty chrono-spec is used for > duration > we are required to format it (and its representation type) via ostream. > Handling this case was now moved to be part of the format function > for duration. To fa

Re: [PATCH v2 3/4] libstdc++: Format empty chrono-spec for the sys_info and local_info directly.

On Thu, 12 Jun 2025, 16:19 Tomasz Kamiński, wrote: > This patch change implementation of the formatters for sys_info and > local_info, > so they no longer delegate to operator<< for ostream in case of empty spec. > As this types may be only formatted with chrono-spec containing only %%, > %t, %n

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

On Thu, 12 Jun 2025, Tomasz Kaminski wrote: > > > > On Thu, Jun 12, 2025 at 5:06 PM Patrick Palka wrote: > On Wed, 11 Jun 2025, Tomasz Kaminski wrote: > > > > > > > On Tue, Jun 10, 2025 at 3:08 AM Patrick Palka > wrote: > >       As with the previous patch, thi

[PATCH] jit: Fix 'gccjit::error' bug when use 'gccjit::struct_' in libgccjit C++ bindings

Hi all, when use the 'gccjit::struct_' with default constructor, just like: gccjit::struct_ a; it will crash with error: gcc_jit_type_as_object: NULL type. terminate called after throwing an instance of 'gccjit::error' because 'struct_' pass a NULL to 'type'. and 'type' call gcc_jit_typ

Re: [PATCH] libstdc++: Test chrono-spec containing only whitespaces.

On Thu, 12 Jun 2025, 16:12 Tomasz Kaminski, wrote: > > > On Thu, Jun 12, 2025 at 4:48 PM Daniel Krügler > wrote: > >> Am Do., 12. Juni 2025 um 16:40 Uhr schrieb Tomasz Kamiński < >> tkami...@redhat.com>: >> >>> libstdc++-v3/ChangeLog: >>> >>> * testsuite/std/time/format/whitespace.cc: Ne

[PATCH v2 4/4] libstdc++: Rework formatting of empty chrono-spec for duration.

In contrast to other calendar types if empty chrono-spec is used for duration we are required to format it (and its representation type) via ostream. Handling this case was now moved to be part of the format function for duration. To facilitate that __formatter_chrono::_M_format_to_ostream function

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

On Thu, 12 Jun 2025, Patrick Palka wrote: > On Wed, 11 Jun 2025, Tomasz Kaminski wrote: > > > > > > > On Tue, Jun 10, 2025 at 3:08 AM Patrick Palka wrote: > > As with the previous patch, this patch reimplements ranges::sort > > directly instead of incorrectly forwarding to std::sor

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

On Thu, Jun 12, 2025 at 5:06 PM Patrick Palka wrote: > On Wed, 11 Jun 2025, Tomasz Kaminski wrote: > > > > > > > On Tue, Jun 10, 2025 at 3:08 AM Patrick Palka wrote: > > As with the previous patch, this patch reimplements ranges::sort > > directly instead of incorrectly forwarding to

[PATCH v2] libstdc++: Format empty chrono-spec for the sys_info and local_info directly.

This patch change implementation of the formatters for sys_info and local_info, so they no longer delegate to operator<< for ostream in case of empty spec. As this types may be only formatted with chrono-spec containing only %%, %t, %n specifiers and fill characters, we use a separate __formatter_c

[PATCH v2 3/4] libstdc++: Format empty chrono-spec for the sys_info and local_info directly.

This patch change implementation of the formatters for sys_info and local_info, so they no longer delegate to operator<< for ostream in case of empty spec. As this types may be only formatted with chrono-spec containing only %%, %t, %n specifiers and fill characters, we use a separate __formatter_c

Re: [PATCH] libstdc++: Test chrono-spec containing only whitespaces.

On Thu, Jun 12, 2025 at 4:48 PM Daniel Krügler wrote: > Am Do., 12. Juni 2025 um 16:40 Uhr schrieb Tomasz Kamiński < > tkami...@redhat.com>: > >> libstdc++-v3/ChangeLog: >> >> * testsuite/std/time/format/whitespace.cc: New test. >> --- >> Testing on x86_64-linux. OK for trunk when test pa

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

On Wed, 11 Jun 2025, Tomasz Kaminski wrote: > > > On Tue, Jun 10, 2025 at 3:08 AM 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 list

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

On Thu, Jun 12, 2025 at 4:56 PM Patrick Palka wrote: > On Wed, 11 Jun 2025, Tomasz Kaminski wrote: > > > > > > > On Wed, Jun 11, 2025 at 1:56 PM Jonathan Wakely > wrote: > > On Wed, 11 Jun 2025 at 12:42, Tomasz Kaminski > wrote: > > > > > > > > > > > > On Tue, Jun

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

On Wed, 11 Jun 2025, Tomasz Kaminski wrote: > > > On Wed, Jun 11, 2025 at 1:56 PM Jonathan Wakely wrote: > On Wed, 11 Jun 2025 at 12:42, Tomasz Kaminski > wrote: > > > > > > > > On Tue, Jun 10, 2025 at 3:05 AM Patrick Palka > wrote: > >> > >> ranges

Re: [r16-1429 Regression] FAIL: g++.target/i386/vect-pragma-target-2.C -std=gnu++98 (test for excess errors) on Linux/x86_64

On Wed, Jun 11, 2025, 10:17 PM haochen.jiang wrote: > On Linux/x86_64, > > dcb9af06212e8bb36e84a1b8498c625c29abeb6f is the first bad commit > commit dcb9af06212e8bb36e84a1b8498c625c29abeb6f > Author: Gwenole Beauchesne > Date: Mon Jun 2 14:44:55 2025 -0700 > > c/c++: Handle '#pragma GCC ta

Re: [PATCH] libstdc++: Test chrono-spec containing only whitespaces.

Am Do., 12. Juni 2025 um 16:40 Uhr schrieb Tomasz Kamiński < tkami...@redhat.com>: > libstdc++-v3/ChangeLog: > > * testsuite/std/time/format/whitespace.cc: New test. > --- > Testing on x86_64-linux. OK for trunk when test passes. > > .../testsuite/std/time/format/whitespace.cc | 54

[PATCH] libstdc++: Test chrono-spec containing only whitespaces.

libstdc++-v3/ChangeLog: * testsuite/std/time/format/whitespace.cc: New test. --- Testing on x86_64-linux. OK for trunk when test passes. .../testsuite/std/time/format/whitespace.cc | 54 +++ 1 file changed, 54 insertions(+) create mode 100644 libstdc++-v3/testsuite/std

[PATCH v2] libstdc++: Format empty chrono-spec for the time points and hh_mm_ss directly.

This patch change implementation of the formatters for time points and hh_mm_ss, so they no longer delegate to operator<< for ostream in case of empty chrono-spec. As in case of calendar types, the formatters for specific type now provide __formatter_chrono with default _ChronoSpec that are used i

Re: [PATCH] RISC-V: Use scratch reg for Rd , so that src/rs2 is not clobbered for Store-Conditional.

On 6/12/25 2:11 AM, Umesh Kalappa wrote: thank you @kito.ch...@sifive.com   and @Jeff Law   ,can you someone please commit the same for us ,if others don't have any comments on these changes  . The right things will happen. I'm just

[committed v2 1/4] libstdc++: Format empty chrono-spec for the calendar types directly.

This patch change implementation of the formatters for the calendar types, so they no longer delegate to operator<< for ostream in case of empty chrono-spec. Instead of that, we define the behavior in terms of format specifiers supplied by each formatter as an argument to _M_parse. Similarly each

[PATCH] AArch64 SIMD: convert mvn+shrn into mvni+subhn

Add an optimization to aarch64 SIMD converting mvn+shrn into mvni+subhn which allows for better optimization when the code is inside a loop by using a constant. Bootstrapped and regtested on aarch64-linux-gnu. Signed-off-by: Remi Machet gcc/ChangeLog:     * config/aarch64/aarch64-simd.md (*s

Re: [PATCH] testsuite: Fix pr119160.c for non-glibc targets [PR119862]

On 6/10/25 1:09 AM, Konstantinos Eleftheriou wrote: Testcase pr119160.c fails with symbol referencing errors for `__cyg_profile_func_enter` and `__cyg_profile_func_exit` on non-glibc systems. This patch adds empty definitions for `__cyg_profile_func_enter` and `__cyg_profile_func_exit` in ord

Re: [PATCH] emit-rtl: Use simplify_subreg_regno to validate hardware subregs [PR119966]

On 6/12/25 4:04 AM, Richard Sandiford wrote: Richard, Jeff, it does not seem appropriate to merge this patch now, given that it breaks avr and or1k. Let me know if such experiment is desired despite the known breakages. It's a bit of a judgment call -- we don't require changes to be clean a

[committed] i386: Fix signed integer overflow in ix86_expand_int_movcc, part 2 [PR120604]

Make sure we can represent the difference between two 64-bit DImode immediate values in 64-bit HOST_WIDE_INT and return false if this is not the case. ix86_expand_int_movcc is used in movcc expadner. Expander will FAIL when the function returns false and middle-end will retry expansion with value

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

On 6/12/25 2:02 AM, Richard Sandiford wrote: I meant it should be opposite: the fold should require SHIFT_COUNT_TRUNCATED (reject !SHIFT_COUNT_TRUNCATED). SHIFT_COUNT_TRUNCATED guarantees that, for a 32-bit shift, A==32 acts like A==0. With !SHIFT_COUNT_TRUNCATED, 1< Right. And to preempt

Re: [PATCH 3/4] libstdc++: Format empty chrono-spec for the sys_info and local_info directly.

On Thu, 12 Jun 2025 at 14:40, Tomasz Kaminski wrote: > > > > On Thu, Jun 12, 2025 at 3:22 PM Jonathan Wakely wrote: >> >> On 06/06/25 12:41 +0200, Tomasz Kamiński wrote: >> >This patch change implementation of the formatters for sys_info and >> >local_info, >> >so they no longer delegate to oper

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

On 6/12/25 1:57 AM, Richard Sandiford wrote: It's probably best to be safe, though it'd be a real surprise to see the shift count being truncated on a shift, but not on a rotate or vice-versa I was thinking that a rotate kind-of has to be truncating, since it isn't really a rotation if it d

  1   2   >