[PATCH] c++: ICE with invalid structured bindings [PR107276]

This test ICEs in C++23 because we reach the new code in do_auto_deduction: 30468 if (cxx_dialect >= cxx23 30469 && context == adc_return_type 30470 && (!AUTO_IS_DECLTYPE (auto_node) 30471 || !unparenthesized_id_or_class_member_access_p (init)) 30472 && (r = treat_lva

[PATCH] c++: Implement -Wdangling-reference [PR106393]

This patch implements a new experimental warning (enabled by -Wextra) to detect references bound to temporaries whose lifetime has ended. The primary motivation is the Note in : Capturing the result of std::max by reference produces a dangling re

Re: Ping (c,c++): Handling of main() function for freestanding

On Fri, 21 Oct 2022, Arsen Arsenović via Gcc wrote: > Ping on this patch. > > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603574.html > > For context, see the rest of this thread. TL;DR is that `int main' > should implicitly return 0 on freestanding, without the other burdens of >

c: tree: target: C2x (...) function prototypes and va_start relaxation

C2x allows function prototypes to be given as (...), a prototype meaning a variable-argument function with no named arguments. To allow such functions to access their arguments, requirements for va_start calls are relaxed so it ignores all but its first argument (i.e. subsequent arguments, if any,

Re: C2x features status

On Friday, 21 October 2022 21:55:53 CEST Florian Weimer wrote: > That's the implicit function declaration/implicit int change. This > won't happen in GCC 13, it's too late for that. I tried to make this > change a couple of years in Fedora, and just flipping the compiler > flag Does Not Work. I

Re: C2x features status

On Friday, 21 October 2022 21:14:54 CEST Marek Polacek via Gcc wrote: > commit 0a91bdaf177409a2a5e7895bce4f0e7091b4b3ca > Author: Joseph Myers > Date: Wed Sep 7 13:56:25 2022 + > > c: New C2x keywords > > which says: > > As with the removal of unprototyped functions, this change h

Re: C2x features status

* Arsen Arsenović: > On Friday, 21 October 2022 21:14:54 CEST Marek Polacek via Gcc wrote: >> commit 0a91bdaf177409a2a5e7895bce4f0e7091b4b3ca >> Author: Joseph Myers >> Date: Wed Sep 7 13:56:25 2022 + >> >> c: New C2x keywords >> >> which says: >> >> As with the removal of unprot

Re: Proxy ping [PATCH] Fortran: Add missing TKR initialization to class variables [PR100097, PR100098]

Hi Mikael, Am 21.10.22 um 13:13 schrieb Mikael Morin: Le 18/10/2022 à 22:48, Harald Anlauf via Fortran a écrit : I intended to add the updated patch but forgot, so here it is... Am 18.10.22 um 22:41 schrieb Harald Anlauf via Fortran: Dear all, Jose posted a patch here that was never reviewed

Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM

On Fri, Oct 21, 2022 at 11:17:39AM +0100, Richard Earnshaw wrote: > On 20/10/2022 18:37, Andrew Pinski via Gcc-patches wrote: > >On aarch64 (armv8), it is actually the same instruction: PRFM. It > >might be the only one which is that way though. > >It even allows to specify the level for the instru

Re: [PATCH] Rename nonzero_bits to known_zero_bits.

On Fri, Oct 21, 2022 at 06:54:32PM +0200, Jakub Jelinek wrote: > On Fri, Oct 21, 2022 at 06:51:19PM +0200, Jakub Jelinek wrote: > > Agreed. > > > > I think maybe_nonzero_bits would be fine. > > Or yet another option is to change what we track and instead of > having just one bitmask have 2 as tre

RE: [PATCH] [X86_64]: Enable support for next generation AMD Zen4 CPU

[Public] Hi all, > Okay, I will prepare another patch which reverts the znver4 instruction > reservations and submit it. PFA the patch which reverts the znver4 instruction reservations. I have also made znver4 to use znver3 scheduler for now. If its good for the trunk, I will submit it. Thanks

Re: [PATCH] Rename nonzero_bits to known_zero_bits.

On Fri, Oct 21, 2022 at 06:51:17PM +0200, Jakub Jelinek wrote: > On Fri, Oct 21, 2022 at 11:45:33AM -0500, Segher Boessenkool wrote: > > On Fri, Oct 21, 2022 at 03:14:26PM +0200, Aldy Hernandez via Gcc-patches > > wrote: > > > * asan.cc (handle_builtin_alloca): Rename *nonzero* to *known_zero*.

Re: [PATCH] Rename nonzero_bits to known_zero_bits.

On Fri, Oct 21, 2022 at 06:51:19PM +0200, Jakub Jelinek wrote: > Agreed. > > I think maybe_nonzero_bits would be fine. Or yet another option is to change what we track and instead of having just one bitmask have 2 as tree-ssa-ccp.cc does, one bitmask says which bits are known to be always the sam

Re: [PATCH] Rename nonzero_bits to known_zero_bits.

On Fri, Oct 21, 2022 at 11:45:33AM -0500, Segher Boessenkool wrote: > On Fri, Oct 21, 2022 at 03:14:26PM +0200, Aldy Hernandez via Gcc-patches > wrote: > > The name nonzero_bits is confusing. We're not tracking nonzero bits. > > We're tracking known-zero bits, or at the worst we're tracking "maye

Re: [PATCH] Rename nonzero_bits to known_zero_bits.

Hi! On Fri, Oct 21, 2022 at 03:14:26PM +0200, Aldy Hernandez via Gcc-patches wrote: > The name nonzero_bits is confusing. We're not tracking nonzero bits. > We're tracking known-zero bits, or at the worst we're tracking "maye > nonzero bits". But really, the only thing we're sure about in the >

vect: Make vect_check_gather_scatter reject offsets that aren't multiples of BITS_PER_UNIT [PR107346]

Hi, The ada failure reported in the PR was being caused by vect_check_gather_scatter failing to deal with bit offsets that weren't multiples of BITS_PER_UNIT. This patch makes vect_check_gather_scatter reject memory accesses with such offsets. Bootstrapped and regression tested on aarch64 an

Re: [PATCH] Always use TYPE_MODE instead of DECL_MODE for vector field

On Fri, Oct 21, 2022 at 2:33 AM Richard Biener wrote: > > On Thu, Oct 20, 2022 at 6:58 PM H.J. Lu via Gcc-patches > wrote: > > > > commit e034c5c895722e0092d2239cd8c2991db77d6d39 > > Author: Jakub Jelinek > > Date: Sat Dec 2 08:54:47 2017 +0100 > > > > PR target/78643 > > PR ta

[PATCH 2/2] analyzer: use std::unique_ptr for pending_diagnostic/note

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. I can self-approve this, but it requires the patch adding make-unique.h as a prerequisite. gcc/analyzer/ChangeLog: * call-info.cc: Add define of INCLUDE_MEMORY. * call-summary.cc: Likewise. * checker-path.cc: L

[PATCH 1/2] Add gcc/make-unique.h

This patch adds gcc/make-unique.h, containing a minimal C++11 implementation of make_unique (std::make_unique is C++14). The followup patch uses this in dozens of places within the analyzer. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. OK for trunk? gcc/ChangeLog: * ma

[PATCH] libstdc++-v3: support for extended floating point types

Hi! The following patch adds support for extended floating point types. C++23 removes the float/double/long double specializations from the spec and instead adds explicit(bool) specifier on the converting constructor. The patch uses that for converting constructor of the base template as well as

[PATCH] builtins: Add various complex builtins for _Float{16,32,64,128,32x,64x,128x}

Hi! On top of the pending https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603665.html https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604080.html the following patch adds some complex builtins which have libm implementation in glibc 2.26 and later on various arches. It is needed for

[RFC] how to handle the combination of -fstrict-flex-arrays + -Warray-bounds

Hi, (FAM below refers to Flexible Array Members): I need inputs on how to handle the combination of -fstrict-flex-arrays + -Warray-bounds. Our initial goal is to update -Warray-bounds with multiple levels of -fstrict-flex-arrays=N to issue warnings according to the different levels of “N”.

Re: [PING][PATCH 0/15] arm: Enables return address verification and branch target identification on Cortex-M

Richard Earnshaw writes: > On 21/09/2022 09:07, Andrea Corallo via Gcc-patches wrote: >> Hi all, >> ping^2 for patches 9/15 7/15 11/15 12/15 and 10/15 V2 of this >> series. >>Andrea > > Subject says xx/15, but I only see 1-12 from you. > > R. Yeah, at the time Srinath asked me to leave space

Re: [PATCH zero-call-used-regs] Add leafy mode for zero-call-used-regs

Hi, Alexandre, Could you please explain a little bit on the motivation of this patch first? thanks. Qing > On Oct 21, 2022, at 3:31 AM, Alexandre Oliva wrote: > > Introduce 'leafy' to auto-select between 'used' and 'all' for leaf and > nonleaf functions, respectively. > > Regstrapped on x86_

RE: [PATCH] [X86_64]: Enable support for next generation AMD Zen4 CPU

[AMD Official Use Only - General] Hi, > I think it may make sense to make the initial patch without scheduler model > update with zen3 scheduling. I can work on updating the model which needs > some benchmarking and setting up > the cost tables first. > The problem here is that adding extra va

[PATCH 2/2] ivopts: Consider number of invariants when calculating register pressure.

From: Dimitrije Milošević This patch slightly modifies register pressure model function to consider both the number of invariants and the number of candidates, rather than just the number of candidates. This used to be the case before c18101f. gcc/ChangeLog: * tree-ssa-loop-ivopts.cc (i

[PATCH 1/2] ivopts: Revert computation of address cost complexity.

From: Dimitrije Milošević This patch reverts the computation of address cost complexity to the legacy one. After f9f69dd, complexity is calculated using the valid_mem_ref_p target hook. Architectures like Mips only allow BASE + OFFSET addressing modes, which in turn prevents the calculation of co

[PATCH 0/2] ivopts: Fix candidate selection for architectures with limited addressing modes.

Architectures like Mips are very limited when it comes to addressing modes. Therefore, the expected behavior would be that, for the BASE + OFFSET addressing mode, complexity is lower, while, for more complex addressing modes (e.g. BASE + INDEX << SCALE), which are not supported, complexity is hi

Re: [PATCH] c++, v2: Don't shortcut TREE_CONSTANT vector type CONSTRUCTORs in cxx_eval_constant_expression [PR107295]

On 10/21/22 03:30, Jakub Jelinek wrote: On Thu, Oct 20, 2022 at 10:51:14AM -0400, Jason Merrill wrote: That seems like a bug; for VECTOR_TYPE we should fold even if !changed. Also, the reason for the short-cutting is I think trying to avoid allocating a new CONSTRUCTOR when nothing changes and

[PATCH] Rename nonzero_bits to known_zero_bits.

The name nonzero_bits is confusing. We're not tracking nonzero bits. We're tracking known-zero bits, or at the worst we're tracking "maye nonzero bits". But really, the only thing we're sure about in the "nonzero" bits are the bits that are zero, which are known to be 0. We're not tracking nonzer

Re: [PATCH] c++ modules: verify_type failure with typedef enum [PR106848]

On Fri, 21 Oct 2022, Nathan Sidwell wrote: > On 10/19/22 09:55, Patrick Palka wrote: > > On Wed, 19 Oct 2022, Richard Biener wrote: > > > > > On Tue, Oct 18, 2022 at 8:26 PM Patrick Palka wrote: > > > > > > > > On Fri, 14 Oct 2022, Richard Biener wrote: > > > > > > > > > On Thu, Oct 13, 2022 a

Re: [PING][PATCH 0/15] arm: Enables return address verification and branch target identification on Cortex-M

On 21/09/2022 09:07, Andrea Corallo via Gcc-patches wrote: Hi all, ping^2 for patches 9/15 7/15 11/15 12/15 and 10/15 V2 of this series. Andrea Subject says xx/15, but I only see 1-12 from you. R.

Re: [PATCH 13/15] arm: Add pacbti related multilib support for armv8.1-m.main.

On 12/08/2022 18:10, Srinath Parvathaneni via Gcc-patches wrote: Hi, This patch supports following -march/-mbranch-protection combination by linking them to existing pacbti multilibs. $ -march=armv8.1-m.main+pacbti+fp.dp+mve.fp -mbranch-protection=standard -mfloat-abi=hard -mthumb $ -mar

Re: [PATCH 10/15 V2] arm: Implement cortex-M return signing address codegen

On 14/09/2022 15:20, Andrea Corallo via Gcc-patches wrote: Hi all, this patch enables address return signature and verification based on Armv8.1-M Pointer Authentication [1]. To sign the return address, we use the PAC R12, LR, SP instruction upon function entry. This is signing LR using SP

Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen4 CPU

> On Fri, Oct 21, 2022 at 12:00 PM Kumar, Venkataramanan via Gcc-patches > wrote: > > > > Hi all, > > > > > -Original Message- > > > From: Joshi, Tejas Sanjay > > > Sent: Monday, October 17, 2022 8:09 PM > > > To: gcc-patches@gcc.gnu.org > > > Cc: Kumar, Venkataramanan ; > > > honza.hubi.

Re: Adding a new thread model to GCC

On 10/21/22 14:29, LIU Hao wrote: 在 2022/10/21 20:13, Jacek Caban 写道: This is not true for past 15 years, CRITICAL_SECTIONS use something like RtlWaitOnAddress (an equivalent of futexes) since Vista, see Wine implementation for details: https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/

Re: [PATCH] c++ modules: verify_type failure with typedef enum [PR106848]

On 10/19/22 09:55, Patrick Palka wrote: On Wed, 19 Oct 2022, Richard Biener wrote: On Tue, Oct 18, 2022 at 8:26 PM Patrick Palka wrote: On Fri, 14 Oct 2022, Richard Biener wrote: On Thu, Oct 13, 2022 at 5:40 PM Patrick Palka via Gcc-patches wrote: Here during stream in we end up having

Re: Adding a new thread model to GCC

On 2022-10-21 12:19, LIU Hao wrote: 在 2022/10/21 19:54, i.nix...@autistici.org 写道: Jacek Caban, who is also a mingw-w64 developer, expressed the same idea a few days ago. While integrating mcfgthread into gcc is practically possible, my concerns are: * GCC never provides a threading li

Re: Adding a new thread model to GCC

On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote: /How does this compare with Eric B's proposal at />>>/https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? />>//>>/My proposal was to reimplement (and extend) the native thread model />>/(win32) />>/instead of adding a new one

Re: [PATCH 9/15] arm: Set again stack pointer as CFA reg when popping if necessary

On 27/09/2022 16:24, Kyrylo Tkachov via Gcc-patches wrote: -Original Message- From: Andrea Corallo Sent: Tuesday, September 27, 2022 11:06 AM To: Kyrylo Tkachov Cc: Andrea Corallo via Gcc-patches ; Richard Earnshaw ; nd Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CF

Re: Adding a new thread model to GCC

在 2022/10/21 20:13, Jacek Caban 写道: This is not true for past 15 years, CRITICAL_SECTIONS use something like RtlWaitOnAddress (an equivalent of futexes) since Vista, see Wine implementation for details: https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/sync.c#L190 Ah Jacek, nice

[PATCH] lto: Always quote path to touch

When generating the makefile, make sure that the paths are quoted so that a native Windows path works within Cygwin. Without this patch, this error is reported by the DejaGNU test suite: make: [T:\ccMf0kI3.mk:3: T:\ccGEvdDp.ltrans0.ltrans.o] Error 1 (ignored) The generated makefile fragment with

Re: Adding a new thread model to GCC

在 2022/10/21 19:54, i.nix...@autistici.org 写道: I have a questions: 1) wouldn't it be logical not to write yet another implementation of pthreads-wor-windows, but to make changes to the winpthreads library because it's already supported by GCC? (maybe I don’t know about some reasons why it wasn

Re: [PATCH 7/15] arm: Emit build attributes for PACBTI target feature

On 12/08/2022 16:30, Andrea Corallo via Gcc-patches wrote: This patch emits assembler directives for PACBTI build attributes as defined by the ABI. gcc/ChangeLog: * config/arm/arm.c (arm_file_start): Emi

Re: Adding a new thread model to GCC

The problem about this approach is that, semaphores are valuable kernel objects, and the maximum number of HANDLEs that a process can open concurrently has a limit (like FDs on Linux), while 'many critical sections are used only occasionally (or never at all), meaning the auto-reset event often

Re: Adding a new thread model to GCC

On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote: How does this compare with Eric B's proposal at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? My proposal was to reimplement (and extend) the native thread model (win32) instead of adding a new one, the advantage being

Re: Adding a new thread model to GCC

On 2022-10-21 11:36, LIU Hao wrote: 在 2022/10/21 18:09, i.nix...@autistici.org 写道: On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote: How does this compare with Eric B's proposal at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? It would be good if we can accept one o

Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen4 CPU

On Fri, Oct 21, 2022 at 12:00 PM Kumar, Venkataramanan via Gcc-patches wrote: > > Hi all, > > > -Original Message- > > From: Joshi, Tejas Sanjay > > Sent: Monday, October 17, 2022 8:09 PM > > To: gcc-patches@gcc.gnu.org > > Cc: Kumar, Venkataramanan ; > > honza.hubi...@gmail.com; Uros Biz

Re: Adding a new thread model to GCC

> How does this compare with Eric B's proposal at > https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? My proposal was to reimplement (and extend) the native thread model (win32) instead of adding a new one, the advantage being that you don't need an extra threading layer between

Re: Adding a new thread model to GCC

在 2022/10/21 18:09, i.nix...@autistici.org 写道: On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote: How does this compare with Eric B's proposal at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? It would be good if we can accept one of them for GCC 13, but I don't know W

Re: Proxy ping [PATCH] Fortran: Add missing TKR initialization to class variables [PR100097, PR100098]

Le 18/10/2022 à 22:48, Harald Anlauf via Fortran a écrit : I intended to add the updated patch but forgot, so here it is... Am 18.10.22 um 22:41 schrieb Harald Anlauf via Fortran: Dear all, Jose posted a patch here that was never reviewed:    https://gcc.gnu.org/pipermail/fortran/2021-April/0

Re: Adding a new thread model to GCC

On 2022-10-21 10:48, Jonathan Wakely wrote: On Fri, 21 Oct 2022 at 11:10, i.nixman--- via Libstdc++ wrote: On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote: > How does this compare with Eric B's proposal at > https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? > > It woul

Re: Adding a new thread model to GCC

On Fri, 21 Oct 2022 at 11:10, i.nixman--- via Libstdc++ wrote: > > On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote: > > How does this compare with Eric B's proposal at > > https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? > > > > It would be good if we can accept one of th

Ping (c,c++): Handling of main() function for freestanding

Ping on this patch. https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603574.html For context, see the rest of this thread. TL;DR is that `int main' should implicitly return 0 on freestanding, without the other burdens of main (hosted should remain unchanged, as well as non-int `main's).

Re: [PATCH 1/2] Add a parameter for the builtin function of prefetch to align with LLVM

On 20/10/2022 18:37, Andrew Pinski via Gcc-patches wrote: On Thu, Oct 20, 2022 at 10:28 AM Segher Boessenkool wrote: On Thu, Oct 20, 2022 at 01:44:15AM +, Jiang, Haochen wrote: Maybe the testcase change cause some misunderstanding and concern. Actually, the patch did not disrupt the p

Re: Adding a new thread model to GCC

On 2022-10-21 09:58, Jonathan Wakely via Libstdc++ wrote: How does this compare with Eric B's proposal at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? It would be good if we can accept one of them for GCC 13, but I don't know Windows well enough to determine which is better.

Re: [PING 3] [PATCH v2] libstdc++: basic_filebuf: don't flush more often than necessary.

On Thu, Oct 6, 2022, 20:03 Charles-Francois Natali wrote: > `basic_filebuf::xsputn` would bypass the buffer when passed a chunk of > size 1024 and above, seemingly as an optimisation. > > This can have a significant performance impact if the overhead of a > `write` syscall is non-negligible, e.g.

Re: Adding a new thread model to GCC

How does this compare with Eric B's proposal at https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? It would be good if we can accept one of them for GCC 13, but I don't know Windows well enough to determine which is better. On Sat, 1 Oct 2022 at 19:35, LIU Hao via Libstdc++ wrote:

RE: [PATCH] [X86_64]: Enable support for next generation AMD Zen4 CPU

Hi all, > -Original Message- > From: Joshi, Tejas Sanjay > Sent: Monday, October 17, 2022 8:09 PM > To: gcc-patches@gcc.gnu.org > Cc: Kumar, Venkataramanan ; > honza.hubi...@gmail.com; Uros Bizjak > Subject: RE: [PATCH] [X86_64]: Enable support for next generation AMD > Zen4 CPU > > [P

Re: [PATCH] libstdc++: respect with-{headers, newlib} for default hosted value

Pushed to trunk, thanks. On Wed, 12 Oct 2022 at 20:48, Arsen Arsenović via Libstdc++ wrote: > > This saves us a build flag when building for freestanding targets. > > libstdc++-v3/ChangeLog: > > * acinclude.m4: Default hosted to off if building without > headers and without newlib

[committed] libstdc++: Fix std::move_only_function for incomplete parameter types

Tested powerpc64le-linux. Pushed to trunk. -- >8 -- The std::move_only_function::__param_t alias template attempts to optimize argument passing for the invoker, by passing by rvalue reference for types that are non-trivial or large. However, the precondition for is_trivally_copyable makes it unsu

Restore 'libgomp.oacc-c-c++-common/nvptx-sese-1.c' SESE regions checking [PR107195, PR107344] (was: [COMMITTED] [PR107195] Set range to zero when nonzero mask is 0.)

Hi! On 2022-10-17T09:43:37+0200, I wrote: > On 2022-10-11T10:31:37+0200, Aldy Hernandez via Gcc-patches > wrote: >> When solving 0 = _15 & 1, we calculate _15 as: >> >> [irange] int [-INF, -2][0, +INF] NONZERO 0xfffe >> >> The known value of _15 is [0, 1] NONZERO 0x1 which is intersecte

Re: [PATCH] Always use TYPE_MODE instead of DECL_MODE for vector field

On Thu, Oct 20, 2022 at 6:58 PM H.J. Lu via Gcc-patches wrote: > > commit e034c5c895722e0092d2239cd8c2991db77d6d39 > Author: Jakub Jelinek > Date: Sat Dec 2 08:54:47 2017 +0100 > > PR target/78643 > PR target/80583 > * expr.c (get_inner_reference): If DECL_MODE of a non-

Re: [PATCH v4] btf: Add support to BTF_KIND_ENUM64 type

On 10/19/22 19:05, Guillermo E. Martinez wrote: Hello, The following is patch v4 to update BTF/CTF backend supporting BTF_KIND_ENUM64 type. Changes from v3: + Remove `ctf_enum_binfo' structure. + Remove -m{little,big}-endian from dg-options in testcase. Comments will be welcomed and appr

Re: [PATCH][AArch64] Improve immediate expansion [PR106583]

Wilco Dijkstra writes: > Hi Richard, > >> Can you do the aarch64_mov_imm changes as a separate patch? It's difficult >> to review the two changes folded together like this. > > Sure, I'll send a separate patch. So here is version 2 again: I still think we should move the functions to avoid the f

[PATCH] tree-optimization/107323 - loop distribution partition ordering issue

The following reverts part of the PR94125 fix which causes us to use a bogus partition ordering after applying versioning for alias to the testcase in PR107323. Instead PR94125 is fixed by appropriately considering to be merged SCCs when skipping edges we want to ignore because of the alias versio

Re: [PATCH] expand: Convert cst - x into cst xor x.

> Do we have evidence that targets properly cost XOR vs SUB RTXen? > > It might actually be a reload optimization - when the constant is > available in a register use 'sub', when it needs to be reloaded > use 'xor'? > > That said, I wonder if the fallout of changing some SUB to XOR > is bigger th

Re: Add 'gcc.dg/tree-ssa/pr107195-3.c' [PR107195] (was: Add 'c-c++-common/torture/pr107195-1.c' [PR107195] (was: [COMMITTED] [PR107195] Set range to zero when nonzero mask is 0.))

On Fri, Oct 21, 2022 at 10:38 AM Thomas Schwinge wrote: > > Hi! > > On 2022-10-21T00:44:30+0200, Aldy Hernandez wrote: > > On Thu, Oct 20, 2022 at 9:22 PM Thomas Schwinge > > wrote: > >> "Add 'gcc.dg/tree-ssa/pr107195-3.c' [PR107195]" attached? > > > > I see 7 different tests in this patch. Di

Re: Add 'gcc.dg/tree-ssa/pr107195-3.c' [PR107195] (was: Add 'c-c++-common/torture/pr107195-1.c' [PR107195] (was: [COMMITTED] [PR107195] Set range to zero when nonzero mask is 0.))

Hi! On 2022-10-21T00:44:30+0200, Aldy Hernandez wrote: > On Thu, Oct 20, 2022 at 9:22 PM Thomas Schwinge > wrote: >> "Add 'gcc.dg/tree-ssa/pr107195-3.c' [PR107195]" attached? > > I see 7 different tests in this patch. Did the 6 that pass, fail > before my patch for PR107195 and are now working

Re: [PATCH] i386: Fix up BFmode comparisons in conditional moves [PR107322]

On Fri, Oct 21, 2022 at 9:15 AM Jakub Jelinek wrote: > > Hi! > > As the testcase shows, when cbranchbf4/cstorebf4 patterns are defined, > we can get ICEs for conditional moves. > The problem is that the generic conditional move expansion just calls > prepare_cmp_insn which just checks that such a

Re: [PATCH] RISC-V: Add type attribute for atomic instructions.

Committed, thanks :) On Fri, Oct 21, 2022 at 1:02 PM Monk Chiang wrote: > > gcc/ChangeLog: > > * config/riscv/riscv.md: Add atomic type attribute. > * config/riscv/sync.md: Add atomic type for atomic instructions. > --- > gcc/config/riscv/riscv.md | 2 +- > gcc/config/riscv/sync

[PATCH zero-call-used-regs] Add leafy mode for zero-call-used-regs

Introduce 'leafy' to auto-select between 'used' and 'all' for leaf and nonleaf functions, respectively. Regstrapped on x86_64-linux-gnu. Ok to install? for gcc/ChangeLog * doc/extend.texi (zero-call-used-regs): Document leafy and variants thereof. * flag-types.h (zero_

[PATCH] c++, v2: Don't shortcut TREE_CONSTANT vector type CONSTRUCTORs in cxx_eval_constant_expression [PR107295]

On Thu, Oct 20, 2022 at 10:51:14AM -0400, Jason Merrill wrote: > That seems like a bug; for VECTOR_TYPE we should fold even if !changed. > > > Also, the reason for the short-cutting is I think trying to avoid > > allocating a new CONSTRUCTOR when nothing changes and we just create > > GC garbage b

[PATCH] libstdc++: Small extended float support tweaks

Hi! The following patch isn't for immediate commit, as it has several dependencies, in particular: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603665.html https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604080.html https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html

[PATCH] builtins: Add __builtin_nextafterf16b builtin

Hi! On top of the pending https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603665.html patch, the following patch adds another needed builtin. The above patch adds among other things __builtin_nextafterf16 builtin which we need in order to constexpr evaluate std::nextafter(_Float16) overload

[PATCH] i386: Fix up BFmode comparisons in conditional moves [PR107322]

Hi! As the testcase shows, when cbranchbf4/cstorebf4 patterns are defined, we can get ICEs for conditional moves. The problem is that the generic conditional move expansion just calls prepare_cmp_insn which just checks that such a cbranch4 exists and returns directly such comparison and passes it

[committed] wwwdocs: style: Simplify handling of containers

This is the change actually triggering most of my changes the last week. With that most of our web pages - the main page is still WIP - should now pass validator.w3.org again: Lose the trailing slash in which we needed to validate (most pages) as XHTML. With that we no longer need to differenti