[PATCH] rs6000: Fix ICE on IEEE128 long double without vsx [PR114402]

Hi, As PR114402 shows, we supports IEEE128 format long double even if there is no vsx support, but there is an ICE about cbranch as the test case shows. For now, we only supports compare:CCFP pattern for IEEE128 fp if TARGET_FLOAT128_HW, so in function rs6000_generate_compare we have a check

[PATCH 2/2] RISC-V: Add cmpmemsi expansion

GCC has a generic cmpmemsi expansion via the by-pieces framework, which shows some room for target-specific optimizations. E.g. for comparing two aligned memory blocks of 15 bytes we get the following sequence: my_mem_cmp_aligned_15: li a4,0 j .L2 .L8: bgeu

[PATCH 1/2] RISC-V: Add tests for cpymemsi expansion

cpymemsi expansion was available for RISC-V since the initial port. However, there are not tests to detect regression. This patch adds such tests. Three of the tests target the expansion requirements (known length and alignment). One test reuses an existing memcpy test from the by-pieces

[PATCH] driver: Move -fdiagnostics-urls= early like -fdiagnostics-color= [PR114980]

In GCC 14 we started to emit URLs for "command-line option is valid for but not " and "-Werror= argument '-Werror=' is not valid for " warnings. So we should have moved -fdiagnostics-urls= early like -fdiagnostics-color=, or -fdiagnostics-urls= wouldn't be able to control URLs in these

[PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

Hi, As the discussion in PR112980, although the current implementation for -fpatchable-function-entry* conforms with the documentation (making N NOPs be consecutive), it's inefficient for both kernel and userspace livepatching (see comments in PR for the details). So this patch is to change the

[PATCH 3/3] RISC-V: Add memset-zero expansion to cbo.zero

The Zicboz extension offers the cbo.zero instruction, which can be used to clean a memory region corresponding to a cache block. The Zic64b extension defines the cache block size to 64 byte. If both extensions are available, it is possible to use cbo.zero to clear memory, if the alignment and size

[PATCH 2/3] RISC-V: testsuite: Make cmo tests LTO safe

Let's add '\t' to the instruction match pattern to avoid false positive matches when compiling with -flto. gcc/testsuite/ChangeLog: * gcc.target/riscv/cmo-zicbom-1.c: Add \t to test pattern. * gcc.target/riscv/cmo-zicbom-2.c: Likewise. * gcc.target/riscv/cmo-zicbop-1.c:

[PATCH 1/3] expr: Export clear_by_pieces()

Make clear_by_pieces() available to other parts of the compiler, similar to store_by_pieces(). gcc/ChangeLog: * expr.cc (clear_by_pieces): Remove static from clear_by_pieces. * expr.h (clear_by_pieces): Add prototype for clear_by_pieces. Signed-off-by: Christoph Müllner ---

[PATCH 0/3] RISC-V: Add memset-zero expansion with Zicboz+Zic64b

I've mentioned this patchset a few weeks ago in the RISC-V call. Sending it now, as the release is out. Christoph Müllner (3): expr: Export clear_by_pieces() RISC-V: testsuite: Make cmo tests LTO safe RISC-V: Add memset-zero expansion to cbo.zero gcc/config/riscv/riscv-protos.h

[PATCH 4/4] tree: Remove KFmode workaround [PR112993]

Hi, The fix for PR112993 makes KFmode have 128 bit mode precision, we don't need this workaround to fix up the type precision any more, and just go with mode precision. So this patch is to remove KFmode workaround. Bootstrapped and regress-tested on: - powerpc64-linux-gnu P8/P9 (with ibm128

[PATCH 3/4] ranger: Revert the workaround introduced in PR112788 [PR112993]

Hi, This reverts commit r14-6478-gfda8e2f8292a90 "range: Workaround different type precision between _Float128 and long double [PR112788]" as the fixes for PR112993 make all 128 bits scalar floating point have the same 128 bit precision, this workaround isn't needed any more. Bootstrapped and

[PATCH 2/4] fortran: Teach get_real_kind_from_node for Power 128 fp modes [PR112993]

Hi, Previously effective target fortran_real_c_float128 never passes on Power regardless of the default 128 long double is ibmlongdouble or ieeelongdouble. It's due to that TF mode is always used for kind 16 real, which has precision 127, while the node float128_type_node for c_float128 has 128

[PATCH 1/4] rs6000: Make all 128 bit scalar FP modes have 128 bit precision [PR112993]

Hi, On rs6000, there are three 128 bit scalar floating point modes TFmode, IFmode and KFmode. With some historical reasons, we defines them with different mode precisions, that is KFmode 126, TFmode 127 and IFmode 128. But in fact all of them should have the same mode precision 128, this

[PATCH 4/4] RISC-V: Allow by-pieces to do overlapping accesses in block_move_straight

The current implementation of riscv_block_move_straight() emits a couple of loads/stores with with maximum width (e.g. 8-byte for RV64). The remainder is handed over to move_by_pieces(). The by-pieces framework utilizes target hooks to decide about the emitted instructions (e.g. unaligned accesses

[PATCH 3/4] RISC-V: tune: Add setting for overlapping mem ops to tuning struct

This patch adds the field overlap_op_by_pieces to the struct riscv_tune_param, which is used by the TARGET_OVERLAP_OP_BY_PIECES_P() hook. This hook is used by the by-pieces infrastructure to decide if overlapping memory accesses should be emitted. The new property is set to false in all tune

[PATCH 2/4] RISC-V: Allow unaligned accesses in cpymemsi expansion

The RISC-V cpymemsi expansion is called, whenever the by-pieces infrastructure will not take care of the builtin expansion. The code emitted by the by-pieces infrastructure may emits code, that includes unaligned accesses if riscv_slow_unaligned_access_p is false. The RISC-V cpymemsi expansion is

[PATCH 1/4] RISC-V: Add test cases for cpymem expansion

We have two mechanisms in the RISC-V backend that expand cpymem pattern: a) by-pieces, b) riscv_expand_block_move() in riscv-string.cc. The by-pieces framework has higher priority and emits a sequence of up to 15 instructions (see use_by_pieces_infrastructure_p() for more details). As a

[PATCH 0/4] RISC-V: Enhance unaligned/overlapping codegen

I've mentioned some improvements for unaligned and overlapping code generation in the RISC-V call a few weeks ago. Sending this patches now, as the release is out. Christoph Müllner (4): RISC-V: Add test cases for cpymem expansion RISC-V: Allow unaligned accesses in cpymemsi expansion

[PATCH v22 20/23] c++: Implement __is_invocable built-in trait

Fixed the reference_wrapper case. I used non_ref_datum_type to avoid potentially multiple build_trait_object calls. -- >8 -- This patch implements built-in trait for std::is_invocable. gcc/cp/ChangeLog: * cp-trait.def: Define __is_invocable. * constraint.cc

Re: [PATCH 2/4] df: Add DF_LIVE_SUBREG problem

Hi Dimitar I send a patch just now, modifies accordingly some comments: Nit: Should have two spaces after the dot, per GNU coding style. I'd suggest to run the contrib/check_GNU_style.py script on your patches. Do you mean "star" by "dot", i.e. "/*" should be "/* "? These names

[PATCH 1/1] Emit cvtne2ps2bf16 for odd increasing perm in __builtin_shufflevector

Hi All This patch updates the GCC x86 backend to efficiently handle odd, incrementally increasing permutations of BF16 vectors using the cvtne2ps2bf16 instruction. It modifies ix86_vectorize_vec_perm_const to support these operations and adds a specific predicate to ensure proper sequence

[df-Add-DF_LIVE_SUBREG-problem] df: Add DF_LIVE_SUBREG problem

From: Lehua Ding This patch add a new DF problem, named DF_LIVE_SUBREG. This problem is extended from the DF_LR problem and support track the subreg liveness of multireg pseudo if these pseudo satisfy the following conditions: 1. the mode size greater than it's REGMODE_NATURAL_SIZE. 2. the

[PATCH] match: `a CMP nonnegative ? a : ABS` simplified to just `ABS` [PR112392]

We can optimize `a == nonnegative ? a : ABS`, `a > nonnegative ? a : ABS` and `a >= nonnegative ? a : ABS` into `ABS`. This allows removal of some extra comparison and extra conditional moves in some cases. I don't remember where I had found though but it is simple to add so let's add it.

[PATCH] x86:Add 3-instruction subroutine vector shift for V16QI in ix86_expand_vec_perm_const_1 [PR107563]

Hi All We've introduced a new subroutine in ix86_expand_vec_perm_const_1 to optimize vector shifting for the V16QI type on x86. This patch uses a three-instruction sequence psrlw, psllw, and por to handle specific vector shuffle operations more efficiently. The change aims to improve assembly

Re: [PATCH 4/4] lra: Apply DF_LIVE_SUBREG data

Hi Vladimir, I'll send V3 patchs based on these comments. Note that these four patches only support subreg liveness tracking and apply to IRA and LRA pass. Therefore, no performance changes are expected before we support subreg coalesce. There will be new patches later to complete the subreg

Re: [PATCH 2/4] df: Add DF_LIVE_SUBREG problem

Hi Dimitar, Thanks for helping to review the code! I will send V3 patch which address these comments. Best, Lehua On 2024/4/26 04:56, Dimitar Dimitrov wrote: On Wed, Apr 24, 2024 at 06:05:03PM +0800, Lehua Ding wrote: This patch add a new DF problem, named DF_LIVE_SUBREG. This problem

[PATCH] x86:Add 3-instruction subroutine vector shift for V16QI in ix86_expand_vec_perm_const_1 [PR107563]

PR target/107563 gcc/ChangeLog: * config/i386/i386-expand.cc (expand_vec_perm_psrlw_psllw_por): New subroutine. (ix86_expand_vec_perm_const_1): New Entry. gcc/testsuite/ChangeLog: * g++.target/i386/pr107563.C: New test. ---

[COMMITTED] Revert "Revert "testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine improvement"" combine improvement

> From: Hans-Peter Nilsson > Date: Thu, 11 Apr 2024 01:16:32 +0200 I committed this revert of a revert, as r15-311, as the prerequisite was also revert-reverted, in r15-268. -- >8 -- This reverts commit 39f81924d88e3cc197fc3df74204c9b5e01e12f7. --- gcc/testsuite/gcc.target/cris/pr93372-2.c |

Ping^3 [PATCH, rs6000] Split TImode for logical operations in expand pass [PR100694]

Hi, As now it's stage-1, gently ping this: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611550.html Gui Haochen Thanks 在 2023/4/24 13:35, HAO CHEN GUI 写道: > Hi, > Gently ping this: > https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611550.html > > Thanks > Gui Haochen > >

Ping [PATCH, RFC] combine: Don't truncate const operand of AND if it's no benefits

Hi, Gently ping this: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647533.html Thanks Gui Haochen 在 2024/3/18 17:10, HAO CHEN GUI 写道: > Hi, > Gently ping this: > https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647533.html > > Thanks > Gui Haochen > > 在 2024/3/11 13:41, HAO

[PATCH] i386: Fix some intrinsics without alignment requirements.

Hi all, This patch aims to fix some intrinsics without alignment requirement, but raised runtime error's problem. Bootstrapped and tested on x86_64-linux-gnu, OK for trunk? BRs, Lin gcc/ChangeLog: PR target/84508 * config/i386/emmintrin.h (_mm_load_sd): Remove

Re: [PATCH] i386: fix ix86_hardreg_mov_ok with lra_in_progress

On Mon, May 6, 2024 at 3:40 PM Kong, Lingling wrote: > > Hi, > Originally eliminate_regs_in_insn will transform > (parallel [ > (set (reg:QI 130) > (plus:QI (subreg:QI (reg:DI 19 frame) 0) > (const_int 96))) > (clobber (reg:CC 17 flag))]) {*addqi_1} > to > (set (reg:QI 130) >

Re: [Patch, rs6000] Enable overlap memory store for block memory clear

Hi, As now it's stage 1, gently ping this: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646478.html Thanks Gui Haochen 在 2024/2/26 10:25, HAO CHEN GUI 写道: > Hi, > This patch enables overlap memory store for block memory clear which > saves the number of store instructions. The

[PATCH] vect: generate suitable convert insn for int -> int, float -> float and int <-> float.

Hi, all This patch aims to optimize __builtin_convertvector. We want the function can generate more efficient insn for some situations. Like v2si -> v2di. The patch has been bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? BRs, Lin gcc/ChangeLog: PR target/107432

[PATCH v1 1/1] RISC-V: Nan-box the result of movbf on soft-bf16

1 This patch implements the Nan-box of bf16. 2 Please refer to the Nan-box implementation of hf16 in: 3 The discussion about Nan-box can be found on the website:

[PATCH v1 0/1] RISC-V: Nan-box the result of movbf on soft-bf16

Compared to the initial patch: 1 Fixed the formatting issue, although the modified format can pass the CI format check, it looks strange. 2 Due to CI not using the latest code for patch, the initial patch build failed. 3 V1

Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

On Tue, May 07, 2024 at 06:34:19PM +, Qing Zhao wrote: > On May 7, 2024, at 13:57, Sebastian Huber > wrote: > > On 07.05.24 16:26, Qing Zhao wrote: > > > Hi, Sebastian, > > > Thanks for your explanation. > > > Our goal is to deprecate the GCC extension on structure > > > containing a

[committed][RISC-V] Turn on overlap_op_by_pieces for generic-ooo tuning

Per quick email exchange with Palmer. Given the triviality, I'm just pushing it. jeffcommit 9f14f1978260148d4d6208dfd73df1858e623758 Author: Jeff Law Date: Tue May 7 15:34:16 2024 -0600 [committed][RISC-V] Turn on overlap_op_by_pieces for generic-ooo tuning Per quick email

Re: [committed] [RISC-V] Allow uarchs to set TARGET_OVERLAP_OP_BY_PIECES_P

On 5/7/24 3:24 PM, Palmer Dabbelt wrote: @@ -529,6 +536,7 @@ static const struct riscv_tune_param generic_ooo_tune_info = { 4, /* fmv_cost */ false, /* slow_unaligned_access */ false,

Re: [committed] [RISC-V] Allow uarchs to set TARGET_OVERLAP_OP_BY_PIECES_P

On Tue, 07 May 2024 14:18:36 PDT (-0700), Jeff Law wrote: > This is almost exclusively work from the VRULL team. > > As we've discussed in the Tuesday meeting in the past, we'd like to have > a knob in the tuning structure to indicate that overlapped stores during > move_by_pieces expansion of

[committed] [RISC-V] Allow uarchs to set TARGET_OVERLAP_OP_BY_PIECES_P

This is almost exclusively work from the VRULL team. As we've discussed in the Tuesday meeting in the past, we'd like to have a knob in the tuning structure to indicate that overlapped stores during move_by_pieces expansion of memcpy & friends are acceptable. This patch adds the that

Re: [PATCH 3/4] gcc/c-family/c-opts: fix quoting for `-fdeps-format=` error message

On Sat, 4 May 2024, Ben Boeckel wrote: > diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc > index be3058dca63..4a164ad0c0b 100644 > --- a/gcc/c-family/c-opts.cc > +++ b/gcc/c-family/c-opts.cc > @@ -370,7 +370,7 @@ c_common_handle_option (size_t scode, const char *arg, > HOST_WIDE_INT

Re: [PATCH] MATCH: Add some more value_replacement simplifications (a != 0 ? expr : 0) to match

On Tue, May 7, 2024 at 1:45 PM Jeff Law wrote: > > > > On 4/30/24 9:21 PM, Andrew Pinski wrote: > > This adds a few more of what is currently done in phiopt's value_replacement > > to match. I noticed this when I was hooking up phiopt's value_replacement > > code to use match and disabling the

Re: [PATCH] PR middle-end/111701: signbit(x*x) vs -fsignaling-nans

On Fri, 3 May 2024, Richard Biener wrote: > So what I do not necessarily agree with is that we need to preserve > the multiplication with -fsignaling-nans. Do we consider a program doing > > handler() { exit(0); } > > x = sNaN; > ... > sigaction(SIGFPE, ... handler) > x*x; >

Re: [PATCH] MATCH: Add some more value_replacement simplifications (a != 0 ? expr : 0) to match

On 4/30/24 9:21 PM, Andrew Pinski wrote: This adds a few more of what is currently done in phiopt's value_replacement to match. I noticed this when I was hooking up phiopt's value_replacement code to use match and disabling the old code. But this can be done independently from the hooking up

Re: [PATCH v3] DCE __cxa_atexit calls where the function is pure/const [PR19661]

On 5/4/24 5:58 PM, Andrew Pinski wrote: In C++ sometimes you have a deconstructor function which is "empty", like for an example with unions or with arrays. The front-end might not know it is empty either so this should be done on during optimization.o To implement it I added it to DCE

Re: [patch,avr] PR114975: Better 8-bit parity detection.

On 5/7/24 11:23 AM, Georg-Johann Lay wrote: Add a combine pattern for parity detection. Ok for master? Johann AVR: target/114975 - Add combine-pattern for __parityqi2. PR target/114975 gcc/ * config/avr/avr.md: Add combine pattern for 8-bit parity detection. gcc/testsuite/

Re: [patch,avr] PR114975: Better 8-bit popcount detection.

On 5/7/24 11:25 AM, Georg-Johann Lay wrote: Add a pattern for better popcount detection. Ok for master? Johann -- AVR: target/114975 - Add combine-pattern for __popcountqi2. PR target/114975 gcc/ * config/avr/avr.md: Add combine pattern for 8-bit popcount detection.

Re: [PATCH] c++: Implement C++26 P2893R3 - Variadic friends [PR114459]

On 5/3/24 12:35, Jakub Jelinek wrote: Hi! The following patch imeplements the C++26 P2893R3 - Variadic friends paper. The paper allows for the friend type declarations to specify more than one friend type specifier and allows to specify ... at the end of each. The patch doesn't introduce

Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

(Resend since my previous email in HTML and inline quoting wasn’t work, I changed the mail setting, hopefully this time it’s good). Sorry for the inconvenience. > On May 7, 2024, at 13:57, Sebastian Huber > wrote: > > On 07.05.24 16:26, Qing Zhao wrote: >> Hi, Sebastian, >> Thanks for your

Re: [PATCH] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

On Tue, May 07, 2024 at 08:57:00PM +0200, Richard Biener wrote: > > > > Am 07.05.2024 um 18:02 schrieb Jakub Jelinek : > > > > Hi! > > > > The HF and BF modes have the same size/precision and neither is > > a subset nor superset of the other. > > So, using either __extendhfbf2 or __trunchfbf2

Re: [PATCH] c++/modules: Stream unmergeable temporaries by value again [PR114856]

On 5/7/24 01:35, Nathaniel Shead wrote: On Thu, May 02, 2024 at 01:53:44PM -0400, Jason Merrill wrote: On 5/2/24 10:40, Patrick Palka wrote: On Thu, 2 May 2024, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/14.2? Another alternative would be to

Re: [PATCH] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

> Am 07.05.2024 um 18:02 schrieb Jakub Jelinek : > > Hi! > > The HF and BF modes have the same size/precision and neither is > a subset nor superset of the other. > So, using either __extendhfbf2 or __trunchfbf2 is weird. > The expansion apparently emits __extendhfbf2, but on the libgcc side

Re: [PATCH] tree-inline: Remove .ASAN_MARK calls when inlining functions into no_sanitize callers [PR114956]

> Am 07.05.2024 um 17:54 schrieb Jakub Jelinek : > > Hi! > > In r9-5742 we've started allowing to inline always_inline functions into > functions which have disabled e.g. address sanitization even when the > always_inline function is implicitly from command line options sanitized. > > This

Re: [PATCH v21 20/23] c++: Implement __is_invocable built-in trait

On Tue, May 7, 2024 at 11:36 AM Jason Merrill wrote: > > On 5/3/24 16:52, Ken Matsui wrote: > > Fixed datum reference problem. Ok for trunk? > > > > -- >8 -- > > > > This patch implements built-in trait for std::is_invocable. > > > > gcc/cp/ChangeLog: > > > > * cp-trait.def: Define

Re: [PATCH v21 20/23] c++: Implement __is_invocable built-in trait

On 5/3/24 16:52, Ken Matsui wrote: Fixed datum reference problem. Ok for trunk? -- >8 -- This patch implements built-in trait for std::is_invocable. gcc/cp/ChangeLog: * cp-trait.def: Define __is_invocable. * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE.

Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

On May 7, 2024, at 13:57, Sebastian Huber wrote: On 07.05.24 16:26, Qing Zhao wrote: Hi, Sebastian, Thanks for your explanation. Our goal is to deprecate the GCC extension on structure containing a flexible array member not at the end of another structure. In order to achieve this goal, we

Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

On 07.05.24 16:26, Qing Zhao wrote: Hi, Sebastian, Thanks for your explanation. Our goal is to deprecate the GCC extension on structure containing a flexible array member not at the end of another structure. In order to achieve this goal, we provided the warning option

[patch,avr] PR114975: Better 8-bit popcount detection.

Add a pattern for better popcount detection. Ok for master? Johann -- AVR: target/114975 - Add combine-pattern for __popcountqi2. PR target/114975 gcc/ * config/avr/avr.md: Add combine pattern for 8-bit popcount detection. gcc/testsuite/ *

[patch,avr] PR114975: Better 8-bit parity detection.

Add a combine pattern for parity detection. Ok for master? Johann AVR: target/114975 - Add combine-pattern for __parityqi2. PR target/114975 gcc/ * config/avr/avr.md: Add combine pattern for 8-bit parity detection. gcc/testsuite/ *

[r15-268 Regression] FAIL: gcc.target/i386/pr101950-2.c scan-assembler-times \txor[ql]\t 2 on Linux/x86_64

On Linux/x86_64, 9dbff9c05520a74e6cd337578f27b56c941f64f3 is the first bad commit commit 9dbff9c05520a74e6cd337578f27b56c941f64f3 Author: Richard Biener Date: Tue May 7 10:14:19 2024 +0200 Revert "Revert "combine: Don't combine if I2 does not change"" caused FAIL:

Re: [PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

On Tue, 7 May 2024 at 17:39, Jonathan Wakely wrote: > > On Tue, 7 May 2024 at 17:33, Jeff Law wrote: > > > > > > > > On 5/7/24 9:36 AM, Andreas Schwab wrote: > > > On Mai 07 2024, Jonathan Wakely wrote: > > > > > >> +#ifdef __riscv > > >> +return _M_insert(__builtin_copysign((double)__f, > >

Re: [PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

On Tue, 7 May 2024 at 17:33, Jeff Law wrote: > > > > On 5/7/24 9:36 AM, Andreas Schwab wrote: > > On Mai 07 2024, Jonathan Wakely wrote: > > > >> +#ifdef __riscv > >> +return _M_insert(__builtin_copysign((double)__f, > >> +

RE: [EXTERNAL] Re: [PATCH v3 00/12] Add aarch64-w64-mingw32 target

Cool - congratulations everyone!! Thanks for getting it completed. Fantastic effort from you all. Zac -Original Message- From: Christophe Lyon Sent: Tuesday, May 7, 2024 6:06 PM To: Evgeny Karpov Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com; Richard Earnshaw (lists) ; Maxim

Re: [PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

On 5/7/24 9:36 AM, Andreas Schwab wrote: On Mai 07 2024, Jonathan Wakely wrote: +#ifdef __riscv + return _M_insert(__builtin_copysign((double)__f, + (double)-__builtin_signbit(__f)); Should this use static_cast? And it's missing a close

Re: [PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

[+Adhemerval and Letu, who handled the glibc side of things, in case they have any more context.] On Tue, 07 May 2024 07:11:08 PDT (-0700), jwak...@redhat.com wrote: On Tue, 7 May 2024 at 15:06, Jonathan Wakely wrote: On Tue, 7 May 2024 at 14:57, Jeff Law wrote: > > > > On 5/7/24 7:49 AM,

[PATCH v2] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]

In this PR, we have to handle a case where MVE predicates are supplied as a const_int, where individual predicates have illegal boolean values (such as 0xc for a 4-bit boolean predicate). To avoid the ICE, we hide the constant behind an unspec. On MVE V8BI and V4BI multi-bit masks are

Re: Fix gnu versioned namespace mode 00/03

Hi François > On 4 May 2024, at 22:11, François Dumont wrote: > > Here is the list of patches to restore gnu versioned namespace mode. > > 1/3: Bump gnu version namespace > > This is important to be done first so that once build of gnu versioned > namespace is fixed there is no chance to

Re: Fix gnu versioned namespace mode 01/03

Hi François As you know I am keen to see this land - but having had some experience with applying previous patches to actual toolchain builds .. > On 4 May 2024, at 22:11, François Dumont wrote: > > libstdc++: Bump gnu versioned namespace to __9 I think that the namespace version should be

Re: [PATCH v3 00/12] Add aarch64-w64-mingw32 target

Hi, I've just pushed this patch series, congratulations! Thanks, Christophe On Thu, 11 Apr 2024 at 15:40, Evgeny Karpov wrote: > > Hello, > > Thank you for reviewing v2! > v3 addresses all comments on v2. > > v3 Changes: > - Exclude the aarch64_calling_abi declaration from the patch series.

[PATCH] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

Hi! The HF and BF modes have the same size/precision and neither is a subset nor superset of the other. So, using either __extendhfbf2 or __trunchfbf2 is weird. The expansion apparently emits __extendhfbf2, but on the libgcc side we apparently have __trunchfbf2 implemented. I think it is easier

[PATCH] tree-inline: Remove .ASAN_MARK calls when inlining functions into no_sanitize callers [PR114956]

Hi! In r9-5742 we've started allowing to inline always_inline functions into functions which have disabled e.g. address sanitization even when the always_inline function is implicitly from command line options sanitized. This mostly works fine because most of the asan instrumentation is done

Re: [wwwdocs] Specify AArch64 BitInt support for little-endian only

On Tue, May 07, 2024 at 02:12:07PM +0100, Andre Vieira (lists) wrote: > Hey Jakub, > > This what ya had in mind? Yes. > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > index > ca5174de991bb088f653468f77485c15a61526e6..924e045a15a78b5702a0d6997953f35c6b47efd1 > 100644 >

Re: [PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

On Mai 07 2024, Jonathan Wakely wrote: > +#ifdef __riscv > + return _M_insert(__builtin_copysign((double)__f, > + (double)-__builtin_signbit(__f)); Should this use static_cast? -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196

Re: [RFA][RISC-V] [PATCH v2] Enable inlining str* by default

On 5/4/24 8:41 AM, Jeff Law wrote: The CI system caught a latent bug in the inline string comparison code that shows up with rv32+zbb.  It was hardcoding 64 when AFAICT it should have been using BITS_PER_WORD. So v2 with that fixed. So per the discussion in today's call I reviewed a couple

Re: [PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

On 5/7/24 8:06 AM, Jonathan Wakely wrote: On Tue, 7 May 2024 at 14:57, Jeff Law wrote: On 5/7/24 7:49 AM, Jonathan Wakely wrote: Do we want this change for RISC-V, to fix PR113578? I haven't tested it on RISC-V, only on x86_64-linux (where it doesn't do anything). -- >8 --

Re: [PATCH] aarch64: Fix typo in aarch64-ldp-fusion.cc:combine_reg_notes [PR114936]

On 03/05/2024 15:45, Alex Coplan wrote: > This fixes a typo in combine_reg_notes in the load/store pair fusion > pass. As it stands, the calls to filter_notes store any > REG_FRAME_RELATED_EXPR to fr_expr with the following association: > > - i2 -> fr_expr[0] > - i1 -> fr_expr[1] > > but then

[patch,avr,applied] PR target/114835 - Tweak __popcountqi2

Applied this tweak as proposed in the PR. Johann -- commit 6b73a9879a4503ebee2cb1a3ad243f60c922ca31 Author: Wolfgang Hospital Date: Tue May 7 16:24:39 2024 +0200 AVR: target/114835 - Tweak popcountqi2 libgcc/ PR target/114835 * config/avr/lib1funcs.S

Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

Hi, Sebastian, Thanks for your explanation. Our goal is to deprecate the GCC extension on structure containing a flexible array member not at the end of another structure. In order to achieve this goal, we provided the warning option -Wflex-array-member-not-at-end for the users to locate all

Re: Ping * 2 [PATCH v9 0/5] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On May 7, 2024, at 10:02, Qing Zhao wrote: 2nd Ping for the middle-end change approval. -:) **Approval status: All C FE changes have been approved. **Review status: All Middle-end changes have been reviewed by Sid, no remaining issue. Okay for GCC15? For convenience, the

Re: [PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

On Tue, 7 May 2024 at 15:06, Jonathan Wakely wrote: > > On Tue, 7 May 2024 at 14:57, Jeff Law wrote: > > > > > > > > On 5/7/24 7:49 AM, Jonathan Wakely wrote: > > > Do we want this change for RISC-V, to fix PR113578? > > > > > > I haven't tested it on RISC-V, only on x86_64-linux (where it doesn't

Re: [PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

On Tue, 7 May 2024 at 14:57, Jeff Law wrote: > > > > On 5/7/24 7:49 AM, Jonathan Wakely wrote: > > Do we want this change for RISC-V, to fix PR113578? > > > > I haven't tested it on RISC-V, only on x86_64-linux (where it doesn't do > > anything). > > > > -- >8 -- > > > > libstdc++-v3/ChangeLog: >

[PATCH 2/2] libstdc++: Fix data races in std::ctype [PR77704]

Tested x86_64-linux. This one is less "obviously correct", as calling the single-character narrow(char, char) overload no longer lazily populates individual characters in the cache (because doing that is racy). And the single-character widen(char) no longer calls _M_wide_init() to populate the

[PATCH 1/2] libstdc++: Fix data race in std::basic_ios::fill() [PR77704]

Tested x86_64-linux. This seems "obviously correct", and I'd like to push it. The current code definitely has a data race, i.e. undefined behaviour. -- >8 -- The lazy caching in std::basic_ios::fill() updates a mutable member without synchronization, which can cause a data race if two threads

Ping * 2 [PATCH v9 0/5] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

2nd Ping for the middle-end change approval. -:) **Approval status: All C FE changes have been approved. **Review status: All Middle-end changes have been reviewed by Sid, no remaining issue. Okay for GCC15? thanks. Qing Begin forwarded message: From: Qing Zhao Subject: Re:

Re: [PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

On 5/7/24 7:49 AM, Jonathan Wakely wrote: Do we want this change for RISC-V, to fix PR113578? I haven't tested it on RISC-V, only on x86_64-linux (where it doesn't do anything). -- >8 -- libstdc++-v3/ChangeLog: PR libstdc++/113578 * include/std/ostream

Re: [PATCH v18 02/26] libstdc++: Optimize std::is_const compilation performance

Hi Jonathan, Since __is_const, __is_volatile, and __is_pointer were approved, could you please review these patches for libstdc++? I guess that you already reviewed almost equivalent patches, but I wanted to make sure. Sincerely, Ken Matsui On Thu, May 2, 2024 at 1:16 PM Ken Matsui wrote: >

Re: [PATCH] libstdc++: Rewrite std::variant comparisons without macros

On Tue, 7 May 2024 at 16:47, Jonathan Wakely wrote: > > I don't think using a macro for these really saves us much, we can do > this to avoid duplication instead. And now it's not a big, multi-line > macro that's a pain to edit. > > Any objections? No, that's beautiful, ship it.

[PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

Do we want this change for RISC-V, to fix PR113578? I haven't tested it on RISC-V, only on x86_64-linux (where it doesn't do anything). -- >8 -- libstdc++-v3/ChangeLog: PR libstdc++/113578 * include/std/ostream (operator<<(basic_ostream&, float)): Restore signbit after

[committed] libstdc++: Fix handling of incomplete UTF-8 sequences in _Unicode_view

Tested x86_64-linux. Pushed to trunk. gcc-14 backport to follow. -- >8 -- Eddie Nolan reported to me that _Unicode_view was not correctly implementing the substitution of ill-formed subsequences with U+FFFD, due to failing to increment the counter when the iterator reaches the end of the

[committed] libstdc++: Fix for -std=c++23 -ffreestanding [PR114866]

Tested x86_64-linux. Pushed to trunk. gcc-14 backport to follow. -- >8 -- std::shared_ptr isn't declared for freestanding, so guard uses of it with #if _GLIBCXX_HOSTED in . libstdc++-v3/ChangeLog: PR libstdc++/114866 * include/bits/out_ptr.h [!_GLIBCXX_HOSTED]: Don't refer to

[PATCH] libstdc++: Rewrite std::variant comparisons without macros

I don't think using a macro for these really saves us much, we can do this to avoid duplication instead. And now it's not a big, multi-line macro that's a pain to edit. Any objections? Tested x86_64-linux. -- >8 -- libstdc++-v3/ChangeLog: * include/std/variant

Re: [PATCH 4/4] libstdc++: Simplify std::variant comparison operators

On Wed, 10 Apr 2024 at 09:51, Jonathan Wakely wrote: > > Tested x86_64-linux. > > This is just a minor clean-up and could wait for stage 1. Pushed now. > > -- >8 -- > > libstdc++-v3/ChangeLog: > > * include/std/variant (_VARIANT_RELATION_FUNCTION_TEMPLATE): > Simplify. > --- >

Re: [PATCH v2] aarch64: Preserve mem info on change of base for ldp/stp [PR114674]

On 12/04/2024 12:13, Richard Sandiford wrote: > Alex Coplan writes: > > This is a v2 because I accidentally sent a WIP version of the patch last > > time round which used replace_equiv_address instead of > > replace_equiv_address_nv; that caused some ICEs (pointed out by the > > Linaro CI) since

[committed] libstdc++: Constrain equality ops for std::pair, std::tuple, std::variant

Tested x86_64-linux. Pushed to trunk. -- >8 -- Implement the changes from P2944R3 which add constraints to the comparison operators of std::pair, std::tuple, and std::variant. The paper also changes std::optional, but we already constrain its comparisons using SFINAE on the return type.

[PATCH] libstdc++: Use __builtin_shufflevector for simd split and concat

Tested on x86_64-linux-gnu and aarch64-linux-gnu and with Clang 18 on x86_64- linux-gnu. OK for trunk and backport(s)? -- 8< Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114958 *

[PATCH] Fix guard for IDF pruning by dominator

When insert_updated_phi_nodes_for tries to skip pruning the IDF to blocks dominated by the nearest common dominator of the set of definition blocks it compares against ENTRY_BLOCK but that's never going to be the common dominator, instead it will be at most its single successor. Re-bootstrap and

Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

On 06.05.24 16:20, Qing Zhao wrote: Hi, Sebastian, Looks like that the behavior you described is correct. What’s your major concern? ( a little confused). I am concerned that the static initialization of structures with flexible array members no longer works. In the RTEMS open source

[wwwdocs] Specify AArch64 BitInt support for little-endian only

Hey Jakub, This what ya had in mind? Kind regards, Andre Vieiradiff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index ca5174de991bb088f653468f77485c15a61526e6..924e045a15a78b5702a0d6997953f35c6b47efd1 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html

[committed] libstdc++: Use https instead of http in some comments

Tested x86_64-linux. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * include/backward/auto_ptr.h: Use https for URL in comment. * include/bits/basic_ios.h: Likewise. * include/std/iostream: Likewise. --- libstdc++-v3/include/backward/auto_ptr.h | 2 +-

  1   2   >