Re: [PATCH] Document locality partitioning params in invoke.texi

On Tue, Apr 22, 2025 at 10:51 AM Kyrylo Tkachov wrote: > > Hi all, > > Filip Kastl pointed out that contrib/check-params-in-docs.py complains > about params not documented in invoke.texi, so this patch adds the short > explanation from params.opt for these to the invoke.texi section. > Thanks for

Re: [PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

On Tue, 22 Apr 2025 at 08:28, Rainer Orth wrote: > > The Linux/sparc64 libstdc++ baselines haven't been updated for years. > This patch fixes that. > > Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk. > > Ok for both? This adds: +TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11 +T

[PATCH] libstdc++: Increase timeouts for format and flat_maps tests

Test for format parse format string and compile time, flat_maps ones test all functionality in single test file. libstdc++-v3/ChangeLog: * testsuite/23_containers/flat_map/1.cc: Add dg-timeout-factor 2. * testsuite/23_containers/flat_multimap/1.cc: Likewise. * testsuite/st

Re: [PATCH] [RISC-V]Support -mcpu for Xuantie cpu

On 4/20/25 9:56 AM, Yixuan Chen wrote: gcc/ChangeLog: * config/riscv/riscv-cores.def (RISCV_TUNE): Add xt-c908, xt-c908v, xt-c910, xt-c910v2, xt-c920, xt-c920v2. (RISCV_CORE): Add xt-c908, xt-c908v, xt-c910, xt-c910v2, xt-c920, xt-c920v2 * config/riscv/riscv.cc: A

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

Hi Richard, > On Tue, Apr 22, 2025 at 12:31 PM Sam James wrote: >> >> Jakub Jelinek writes: >> >> > On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote: >> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote: >> >> > >> >> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wr

[PATCH v2] libstdc++: Implement formatters for queue, priority_queue and stack [PR109162]

This patch implements formatter specializations for standard container adaptors (queue, priority_queue and stack) from P2286R8. To be able to access the protected `c` member, the adaptors befriend corresponding formatter specializations. Note that such specialization may be disable if the containe

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

Hi Jerry, hi Paul, thanks for the review. Committed as gcc-16-79-g6e3b92848b5 (for the 6 of 5 commit) on mainline. Thanks again for the fast review. Regards, Andre On Fri, 18 Apr 2025 18:27:03 -0700 Jerry D wrote: > On 4/18/25 9:13 AM, Paul Richard Thomas wrote: > > Hi Andre, > > >

Re: [PATCH] Add a bootstrap-native build config

On Sat, Apr 12, 2025 at 5:09 PM Andi Kleen wrote: > > From: Andi Kleen > > ... that uses -march=native -mtune=native to build a compiler optimized > for the host. -march=native implies -mtune=native so I think the latter is redundant. > config/ChangeLog: > > * bootstrap-native.mk: New f

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

On Tue, Apr 22, 2025 at 01:14:51PM +0200, Rainer Orth wrote: > what about trunk then? Right now, cobol still doesn't build there on > Solaris/amd64 because 3 patches are missing: > > cobol: Don't require GLOB_BRACE etc. [PR119217] > https://gcc.gnu.org/pipermail/gcc-patches/2025-Apr

[PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

The Linux/sparc64 libstdc++ baselines haven't been updated for years. This patch fixes that. Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk. Ok for both? Rainer -- - Rainer Orth, Center

[PATCH] libstdc++: Implement formatters for queue, priority_queue and stack [PR109162]

This patch implements formatter specializations for standard container adaptors (queue, priority_queue and stack) from P2286R8. To be able to access the protected `c` member, the adaptors befriend corresponding formatter specializations. Note that such specialization may be disable if the containe

Re: Improve vectorizer costs of min, max, abs, absu and const_expr on x86

On Mon, 21 Apr 2025, Jan Hubicka wrote: > Hi, > this patch adds special cases for vectorizer costs in COND_EXPR, MIN_EXPR, > MAX_EXPR, ABS_EXPR and ABSU_EXPR. We previously costed ABS_EXPR and > ABSU_EXPR > but it was only correct for FP variant (wehre it corresponds to andss clearing > sign bi

Adjust 'libgomp.c++/target-exceptions-pr118794-1.C' for 'targetm.arm_eabi_unwinder' [PR118794] (was: [Linaro-TCWG-CI] gcc-15-9463-gaa3e72f9430: 2 regressions on arm)

Hi! On 2025-04-17T18:15:50+, ci_notify--- via Gcc-regression wrote: > Our automatic CI has detected problems related to your patch(es). Please find > some details below. > > In bootstrap_check master-arm-check_bootstrap, after: > | commit gcc-15-9463-gaa3e72f9430 > | Author: Thomas Schw

Re: [PATCH v2] libstdc++: Implement formatters for queue, priority_queue and stack [PR109162]

On Tue, 22 Apr 2025 at 12:19, Tomasz Kamiński wrote: > > This patch implements formatter specializations for standard container > adaptors > (queue, priority_queue and stack) from P2286R8. > > To be able to access the protected `c` member, the adaptors befriend > corresponding formatter specializ

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

Jakub Jelinek writes: > On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote: >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote: >> > >> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote: >> > > That's one option, but maybe it's better the other way round: instead of >

[PATCH] libstdc++: Update baseline_symbols.txt for {x86_64,i486,powerpc64le,s390x,aarch64}-linux

Hi! We forgot to update these timely, sorry for that, the following patch updates them from the 15.1-rc1 builds in Fedora. Ok for trunk and 15? 2025-04-22 Jakub Jelinek * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update. * config/abi/post/x86_64-linux-gnu/32/base

Re: [PHASE1 PATCH] Use optimize free lists for alloc_pages

On Fri, Apr 11, 2025 at 6:10 PM Andi Kleen wrote: > > Right now ggc has a single free list for multiple sizes. In some cases > the list can get mixed by orders and then the allocator may spend a lot > of time walking the free list to find the right sizes. > > This patch splits the free list into m

Re: [PATCH stage1 0/6] Correct outgoing integer argument promotion

On Fri, Mar 14, 2025 at 11:51 PM H.J. Lu wrote: > > 1. Honor TARGET_PROMOTE_PROTOTYPES during RTL expand. > 2. Drop targetm.promote_prototypes from C, C++ and Ada frontends. > 3. Adjust tests for the C frontend promotion removal. > 4. gcc.dg/tree-ssa/pr108357.c fails with the C frontend promotion

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

Hi Jakub, > On Tue, Apr 22, 2025 at 01:14:51PM +0200, Rainer Orth wrote: >> what about trunk then? Right now, cobol still doesn't build there on >> Solaris/amd64 because 3 patches are missing: >> >> cobol: Don't require GLOB_BRACE etc. [PR119217] >> https://gcc.gnu.org/pipermail/gcc

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

Jakub Jelinek writes: > On Tue, Apr 22, 2025 at 01:26:44PM +0200, Rainer Orth wrote: >> fine with me. This way there's no hurry with the other patches for fear >> of either breaking the build on non-Linux platforms or impacting COBOL >> on Linux. > > No rush, sure, on the other side, better reso

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

On Tue, Apr 22, 2025 at 01:26:44PM +0200, Rainer Orth wrote: > fine with me. This way there's no hurry with the other patches for fear > of either breaking the build on non-Linux platforms or impacting COBOL > on Linux. No rush, sure, on the other side, better resolve all those in stage1...

Re: [PATCH] testsuite: Use sigsetjmp in gcc.misc-tests/gcov-31.c

Hi, Thanks for fixing this. I just checked glibc, which implements __sigsetjmp as: # define sigsetjmp(env, savemask) __sigsetjmp (env, savemask) So I would think this is fine. I leave the ack to the Jakub, Richard et al, of course. Thanks, Jørgen On 2025-04-22 10:33, Rainer Orth wrote: T

[PATCH] s390: Allow 5+ argument tail-calls in some special cases [PR119873]

Hi! protobuf (and therefore firefox too) currently doesn't build on s390*-linux. The problem is that it uses [[clang::musttail]] attribute heavily, and in llvm (IMHO llvm bug) [[clang::musttail]] calls with 5+ arguments on s390*-linux are silently accepted and result in a normal non-tail call. In

[PATCH] testsuite: Use sigsetjmp in gcc.misc-tests/gcov-31.c

The gcc.misc-tests/gcov-31.c test FAILs on Solaris and Darwin: FAIL: gcc.misc-tests/gcov-31.c (test for excess errors) Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.misc-tests/gcov-31.c:23:5: error: implicit declaration of function '__sigsetjmp'; did you mean 'sigsetjmp'? [-Wimp

Re: [PATCH] libstdc++: Finalize GCC 15 ABI

On Sat, 19 Apr 2025 at 13:12, Andreas Schwab wrote: > > Disallow adding new symbols to GLIBCXX_3.4.34 and CXXABI_1.3.16 versions. > > * testsuite/util/testsuite_abi.cc (check_version): Update latestp > to use GLIBCXX_3.4.35 and CXXABI_1.3.17. OK for trunk, thanks. > --- > libst

Re: [PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

Hi Jonathan, > On Tue, 22 Apr 2025 at 08:28, Rainer Orth > wrote: >> >> The Linux/sparc64 libstdc++ baselines haven't been updated for years. >> This patch fixes that. >> >> Tested on sparc64-unknown-linux-gnu on both the gcc-15 branch and trunk. >> >> Ok for both? > > This adds: > > +TLS:8:_ZSt

Re: [PATCH] testsuite: Use sigsetjmp in gcc.misc-tests/gcov-31.c

On Tue, 22 Apr 2025, Rainer Orth wrote: > The gcc.misc-tests/gcov-31.c test FAILs on Solaris and Darwin: > > FAIL: gcc.misc-tests/gcov-31.c (test for excess errors) > > Excess errors: > /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.misc-tests/gcov-31.c:23:5: > error: implicit declaration of fu

[committed (Apr 17 to GCC 15 mainline)] libgomp.texi: For HIP interop, mention cpp defines to set

I just saw that I seemingly have missed to send this patch also to the mailing list :-( It was committed to what was back then still mainline GCC 15:r15-9545-g4bff3f0b89af9a Result after the patch: https://gcc.gnu.org/onlinedocs/libgomp/Foreign-runtime-support-for-AMD-GPUs.html and https://gc

Re: [PATCH] libstdc++: Update baseline_symbols.txt for {x86_64, i486, powerpc64le, s390x, aarch64}-linux

On Tue, 22 Apr 2025 at 09:29, Jonathan Wakely wrote: > > On Tue, 22 Apr 2025 at 08:58, Jakub Jelinek wrote: > > > > Hi! > > > > We forgot to update these timely, sorry for that, the following patch > > updates them from the 15.1-rc1 builds in Fedora. > > > > Ok for trunk and 15? > > > > 2025-04-2

Re: [PATCH] libstdc++: Update Solaris baselines for GCC 15.1

On Tue, 22 Apr 2025 at 09:04, Jakub Jelinek wrote: > > On Tue, Apr 22, 2025 at 09:18:14AM +0200, Rainer Orth wrote: > > This patch updates the Solaris libstdc++ baselines for GCC 15.1. > > > > Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 on both the > > gcc-15 branch and trunk. > > > >

Re: [PATCH] libstdc++: Update baseline_symbols.txt for {x86_64,i486,powerpc64le,s390x,aarch64}-linux

On Tue, Apr 22, 2025 at 09:29:16AM +0100, Jonathan Wakely wrote: > On Tue, 22 Apr 2025 at 08:58, Jakub Jelinek wrote: > > We forgot to update these timely, sorry for that, the following patch > > updates them from the 15.1-rc1 builds in Fedora. > > > > Ok for trunk and 15? > > > > 2025-04-22 Jaku

RE: [PATCH] Add COBOL information to gcc.gnu.org index.html

On Thu, 17 Apr 2025, Robert Dubner wrote: > In the absence of commentary, I have pushed those documentation changes. This is fine. You can also copy me on wwwdocs changes, though that's certainly not required (and I do have filters to focus on these on gcc-patches). Gerald

[PATCH] Document locality partitioning params in invoke.texi

Hi all, Filip Kastl pointed out that contrib/check-params-in-docs.py complains about params not documented in invoke.texi, so this patch adds the short explanation from params.opt for these to the invoke.texi section. Thanks for the reminder. Ok for trunk and GCC 15 branch? Kyrill Signed-off-by:

Re: [PATCH] x86: Properly find the maximum stack slot alignment

On Sun, Apr 20, 2025 at 11:26 PM H.J. Lu wrote: > > Don't assume that stack slots can only be accessed by stack or frame > registers. We first find all registers defined by stack or frame > registers. Then check memory accesses by such registers, including > stack and frame registers. > > gcc/ >

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote: > On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote: > > > > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote: > > > That's one option, but maybe it's better the other way round: instead of > > > excluding known-bad targe

Re: [PATCH v4 3/4] libstdc++: Implement std::extents [PR107761].

On Fri, Apr 18, 2025 at 7:48 PM Luc Grosheintz wrote: > > On 4/18/25 2:00 PM, Tomasz Kaminski wrote: > > > > > > > > On Fri, Apr 18, 2025 at 1:43 PM Luc Grosheintz > > wrote: > > > > This implements std::extents from according to N4950 and > > contains p

[PATCH] libstdc++: Update baseline symbols for riscv64-linux

* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update. --- .../post/riscv64-linux-gnu/baseline_symbols.txt | 15 +++ 1 file changed, 15 insertions(+) diff --git a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt b/libstdc++-v3/config/abi/post/

Re: [PATCH] libstdc++: Implement formatters for queue, priority_queue and stack [PR109162]

On 22/04/25 09:38 +0200, Tomasz Kamiński wrote: This patch implements formatter specializations for standard container adaptors (queue, priority_queue and stack) from P2286R8. To be able to access the protected `c` member, the adaptors befriend corresponding formatter specializations. Note that

Re: [PATCH] libstdc++: Update baseline_symbols.txt for m68k-linux

On Tue, 22 Apr 2025 at 10:25, Andreas Schwab wrote: > > * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update. OK for trunk and gcc-15 (confirmed by Jakub on IRC). Thanks. > --- > .../abi/post/m68k-linux-gnu/baseline_symbols.txt | 11 +++ > 1 file changed, 11 inser

Re: [PATCH] libstdc++: Update baseline symbols for riscv64-linux

On Tue, 22 Apr 2025 at 11:43, Andreas Schwab wrote: > > * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update. OK for trunk and gcc-15 (confirmed by Jakub on IRC). > --- > .../post/riscv64-linux-gnu/baseline_symbols.txt | 15 +++ > 1 file changed, 15 insertions(+

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

On Tue, Apr 22, 2025 at 12:31 PM Sam James wrote: > > Jakub Jelinek writes: > > > On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote: > >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote: > >> > > >> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote: > >> > > That's o

Re: [PATCH] sanitizer: Store no_sanitize attribute value in uint32 instead of unsigned

Kees Cook writes: > On Thu, Apr 10, 2025 at 05:17:51PM -0700, Keith Packard wrote: >> A target using 16-bit ints won't have enough bits to hold the whole >> flag_sanitize set. Be explicit about using uint32 for the attribute data. >> >> Signed-off-by: Keith Packard >> --- >> gcc/c-family/c-att

Re: [PATCH] libstdc++: Strip reference and cv-qual in range deduction guides for maps.

The test cover constructors introduced in [PATCH v2] libstdc++-v3: Implement missing allocator-aware constructors for unordered containers, so I will merge that after. On Fri, Apr 18, 2025 at 5:18 PM Jonathan Wakely wrote: > > > On Fri, 18 Apr 2025, 12:55 Tomasz Kamiński, wrote: > >> This imple

Re: [PATCH 1/2] icf: Remove nop code from sem_function::init.

Hi, On Thu, Apr 17 2025, Andrew Pinski wrote: > Here we had: > node = node; > Which does nothing so let's remove it. > > gcc/ChangeLog: > > * ipa-icf.cc (sem_function::init): Remove assignment of node from > itself. I'm not sure if you meant to push this as obvious or whether you were lo

Re: [PATCH 1/2] icf: Remove nop code from sem_function::init.

On Tue, Apr 22, 2025 at 12:11 AM Martin Jambor wrote: > > Hi, > > On Thu, Apr 17 2025, Andrew Pinski wrote: > > Here we had: > > node = node; > > Which does nothing so let's remove it. > > > > gcc/ChangeLog: > > > > * ipa-icf.cc (sem_function::init): Remove assignment of node from > > its

Re: [PATCH] gimple: Canonical order for invariants [PR118902]

On Tue, Apr 22, 2025 at 1:06 AM Andrew Pinski wrote: > > On Mon, Apr 21, 2025 at 1:42 AM Richard Biener > wrote: > > > > On Thu, Apr 17, 2025 at 7:37 PM Andrew Pinski > > wrote: > > > > > > So unlike constants, address invariants are currently put first if > > > used with a SSA NAME. > > > It w

Re: [PATCH 2/2] icf: Remove unused constructors of sem_function and sem_variable

Hi, On Thu, Apr 17 2025, Andrew Pinski wrote: > The constructors for sem_function and sem_variable that just > passes the bitmap obstack and NOT the cgraph node was unused > so let's remove it. > > gcc/ChangeLog: > > * ipa-icf.cc (sem_function::sem_function): Remove > the obstack argum

[PATCH] libstdc++: Update Solaris baselines for GCC 15.1

This patch updates the Solaris libstdc++ baselines for GCC 15.1. Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 on both the gcc-15 branch and trunk. Ok for both? Rainer -- - Rainer Orth, Center for Bio

Re: [PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

Hi Jonathan, > On Tue, 22 Apr 2025 at 09:47, Rainer Orth > wrote: >> >> Hi Jonathan, >> >> > On Tue, 22 Apr 2025 at 08:28, Rainer Orth >> > wrote: >> >> >> >> The Linux/sparc64 libstdc++ baselines haven't been updated for years. >> >> This patch fixes that. >> >> >> >> Tested on sparc64-unknown

Re: [PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

On Tue, Apr 22, 2025 at 11:32:43AM +0200, Rainer Orth wrote: > Hi Jonathan, > > > On Tue, 22 Apr 2025 at 09:47, Rainer Orth > > wrote: > >> > >> Hi Jonathan, > >> > >> > On Tue, 22 Apr 2025 at 08:28, Rainer Orth > >> > wrote: > >> >> > >> >> The Linux/sparc64 libstdc++ baselines haven't been up

Re: [PATCH] libstdc++: Increase timeouts for format and flat_maps tests

On Tue, 22 Apr 2025 at 10:03, Tomasz Kamiński wrote: > > Test for format parse format string and compile time, > flat_maps ones test all functionality in single test file. > > libstdc++-v3/ChangeLog: > > * testsuite/23_containers/flat_map/1.cc: Add dg-timeout-factor 2. > * testsuit

Re: [PATCH] libstdc++: Update Linux/sparc64 baselines for GCC 15.1

On Tue, 22 Apr 2025 at 09:47, Rainer Orth wrote: > > Hi Jonathan, > > > On Tue, 22 Apr 2025 at 08:28, Rainer Orth > > wrote: > >> > >> The Linux/sparc64 libstdc++ baselines haven't been updated for years. > >> This patch fixes that. > >> > >> Tested on sparc64-unknown-linux-gnu on both the gcc-1

Re: [PATCH] Add COBOL to htdocs/gcc-15/changes.html.

On Thu, 17 Apr 2025, Robert Dubner wrote: > Adds a COBOL section to htdocs/gcc-15/changes.html. There was an extra in there which I just fixed (= pushed). (The first hunk is just a whitespace change to align more closely with the rest of the page; the fix is in the second hunk.) Gerald commi

Re: [PATCH] libstdc++: Update baseline_symbols.txt for {x86_64, i486, powerpc64le, s390x, aarch64}-linux

On Tue, 22 Apr 2025 at 09:49, Jakub Jelinek wrote: > > On Tue, Apr 22, 2025 at 09:29:16AM +0100, Jonathan Wakely wrote: > > On Tue, 22 Apr 2025 at 08:58, Jakub Jelinek wrote: > > > We forgot to update these timely, sorry for that, the following patch > > > updates them from the 15.1-rc1 builds in

[PATCH] libstdc++: Update baseline_symbols.txt for m68k-linux

* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update. --- .../abi/post/m68k-linux-gnu/baseline_symbols.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt b/libstdc++-v3/config/abi/post/m68k-li

Re: [PATCH] libstdc++: Update Solaris baselines for GCC 15.1

On Tue, Apr 22, 2025 at 09:18:14AM +0200, Rainer Orth wrote: > This patch updates the Solaris libstdc++ baselines for GCC 15.1. > > Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 on both the > gcc-15 branch and trunk. > > Ok for both? > > Rainer > > -- >

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

On Mon, Apr 21, 2025 at 10:16:39AM +0100, Sam James wrote: > Sam James writes: > > > Richard Biener writes: > > > >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote: > >>> > >>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote: > >>> > That's one option, but maybe it's better the

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

Jakub Jelinek writes: > On Mon, Apr 21, 2025 at 10:16:39AM +0100, Sam James wrote: >> Sam James writes: >> >> > Richard Biener writes: >> > >> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote: >> >>> >> >>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote: >> >>> > That's one

Re: [PATCH] libstdc++: Update baseline_symbols.txt for {x86_64, i486, powerpc64le, s390x, aarch64}-linux

On Tue, 22 Apr 2025 at 08:58, Jakub Jelinek wrote: > > Hi! > > We forgot to update these timely, sorry for that, the following patch > updates them from the 15.1-rc1 builds in Fedora. > > Ok for trunk and 15? > > 2025-04-22 Jakub Jelinek > > * config/abi/post/x86_64-linux-gnu/baseline_s

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

/* TODO: We set RVV instruction cost as 1 by default. Cost Model need to be well analyzed and supported in the future. */ + int cost_val = 1; + enum rtx_code rcode = GET_CODE (x); + + /* Aka (vec_duplicate:RVVM1DI (reg/v:DI 143 [ x ])) */ + if (rcode == VEC_DUPLICATE && SCALAR_INT_MO

Re: [pushed] c++: ill-formed constexpr function [PR113360]

On 4/17/25 10:06 AM, Patrick Palka wrote: On Wed, 16 Apr 2025, Jason Merrill wrote: If we already gave an error while parsing a function, we don't also need to try to explain what's wrong with it when we later try to use it in a constant-expression. In the new testcase explain_invalid_constexp

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

On 4/21/25 6:46 AM, Nathaniel Shead wrote: I don't really know how OpenMP works, hopefully this makes sense. Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? And for 15 (I guess after release)? This is OK with a FIXME; presumably if we want to support running static constructor

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

On Tue, Apr 22, 2025 at 10:47:31AM -0400, Jason Merrill wrote: > On 4/21/25 6:46 AM, Nathaniel Shead wrote: > > I don't really know how OpenMP works, hopefully this makes sense. > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > And for 15 (I guess after release)? > > This is

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

Jason Merrill wrote: This is OK with a FIXME; presumably if we want to support running static constructors on the offload target we will eventually want to support that in modules as well. Well, the code that added support for static constructors on the offload target exposed the issue. Thus

[PATCH] Document AArch64 changes for GCC 15

The list is structured as: - new configurations - command-line changes - ACLE changes - everything else As usual, the list of new architectures, CPUs, and features is from a purely mechanical trawl of the associated .def files. I've identified features by their architectural name to try to impro

Re: [PATCH] Document AArch64 changes for GCC 15

> On 22 Apr 2025, at 15:31, Tamar Christina wrote: > >> -Original Message- >> From: Richard Sandiford >> Sent: Tuesday, April 22, 2025 2:28 PM >> To: Tamar Christina >> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ; >> ktkac...@nvidia.com >> Subject: Re: [PATCH] Document AArch64 cha

RE: [PATCH] Document AArch64 changes for GCC 15

> -Original Message- > From: Richard Sandiford > Sent: Tuesday, April 22, 2025 1:31 PM > To: gcc-patches@gcc.gnu.org > Cc: Richard Earnshaw ; ktkac...@nvidia.com; > Tamar Christina > Subject: [PATCH] Document AArch64 changes for GCC 15 > > The list is structured as: > > - new configurat

Re: [PATCH] avoid-store-forwarding: Fix reg init on load-elimination [PR119160]

After reviewing the entire dependencies to get this enabled by default, our current plan is as follows: 1. Send a v2 (there still were outstanding comments against some testcases) of the "turn on by default for -O2" patch. 2. Address PR118873, PR119862, and PR119884 before merging the patch that tu

Ping: [RFA, GCC 15] testsuite: XFAIL predcom-8.c on aarch64 [PR118407]

Ping, since it sounds from irc like the release is coming soon :) Richard Sandiford writes: > gcc.dg/tree-ssa/predcom-8.c fails on aarch64 for the reasons discussed > in the PR trail. The fix didn't make it into GCC 15, so this patch > XFAILs the test instead. > > Other targets might benefit fro

Re: [PATCH] asf: Enable pass at O2 or higher

We have sent a new version for this, with updated testcases (https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681606.html). Thanks, Konstantinos On Wed, Jan 29, 2025 at 8:32 PM Richard Sandiford wrote: > > Christoph Müllner writes: > > The avoid-store-forwarding pass is disabled by default

[PATCH 2/2] libstdc++: Define __cpp_lib_format_ranges in format header [PR109162]

As P2286R8 and P2585R1 as now fully implemented, we now define __cpp_lib_format_ranges feature test macro with __cpp_lib_format_ranges. This macro is provided only in . Uses of internal __glibcxx_format_ranges are also updated. PR libstdc++/109162 libstdc++-v3/ChangeLog: * inclu

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

Jason Merrill wrote: On 4/22/25 11:04 AM, Tobias Burnus wrote: The question is why does this code trigger at all, given that there is OpenMP but no offload code at all? And how to fix it in case there is offload code and modules are used. This seems to be because of:   if (module_global_init

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

On Tue, Apr 22, 2025 at 07:21:14PM +0200, Tobias Burnus wrote: > I currently do not see whether the code is needed in this case or not, but I > assume it is, if we want to support static initializers?!? > > In any case, it seems as if the condition 'if (flag_openmp)' additionally > requires '&& lo

Re: Adjust 'libgomp.c++/target-exceptions-pr118794-1.C' for 'targetm.arm_eabi_unwinder' [PR118794] (was: [Linaro-TCWG-CI] gcc-15-9463-gaa3e72f9430: 2 regressions on arm)

Hi! On Tue, 22 Apr 2025 at 13:55, Thomas Schwinge wrote: > > Hi! > > On 2025-04-17T18:15:50+, ci_notify--- via Gcc-regression > wrote: > > Our automatic CI has detected problems related to your patch(es). Please > > find some details below. > > > > In bootstrap_check master-arm-check_boots

Re: [patch fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

Ping! Can we backport this to 15 please? Regards, Jerry On 4/18/25 6:35 PM, Jerry D wrote: On 4/18/25 5:48 PM, Jerry D wrote: I will be committing a fix for this to the 16 mainline tonight. I am requesting Release Manager approval to push to 15 release branch after full testing here. Rega

[Fortran, Patch, PR119200, v1] Use correct locus while check()ing coarray functions.

Hi all, attached patch fixes an illegal use of gfc_current_locus during the check()-phase of several coarray functions. Instead gfc_current_intrinsic_where needs to be used. This error does not crash gfortran reliably. But valgrind reports an access to uninitialized memory. I therefore do not know

Re: [PHASE1 PATCH] Use optimize free lists for alloc_pages

On Tue, Apr 22, 2025 at 01:27:34PM +0200, Richard Biener wrote: > I assume this passed bootstrap & regtest? Yes it did > > This is OK for trunk after we've released GCC 15.1. Thanks. Andi

Re: [PATCH] Document AArch64 changes for GCC 15

Tamar Christina writes: >> -Original Message- >> From: Richard Sandiford >> Sent: Tuesday, April 22, 2025 1:31 PM >> To: gcc-patches@gcc.gnu.org >> Cc: Richard Earnshaw ; ktkac...@nvidia.com; >> Tamar Christina >> Subject: [PATCH] Document AArch64 changes for GCC 15 >> >> The list is st

RE: [PATCH] Document AArch64 changes for GCC 15

> -Original Message- > From: Richard Sandiford > Sent: Tuesday, April 22, 2025 2:28 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ; > ktkac...@nvidia.com > Subject: Re: [PATCH] Document AArch64 changes for GCC 15 > > Tamar Christina writes: > >> -Original

[RFA, GCC 15] aarch64: Define __ARM_FEATURE_FAMINMAX

We implemented FAMINMAX ACLE support but failed to define the associated feature macro. Tested on aarch64-linux-gnu & pushed to trunk. OK for GCC 15 too? Sorry for the late patch. I only noticed this macro was missing while writing up the GCC 15 changes. It would be good to get it in for 15.1

[PATCH v2] asf: Enable pass at O2 or higher

The avoid-store-forwarding pass is disabled by default and therefore in the risk of bit-rotting. This patch addresses this by enabling the pass at O2 or higher. The assembly patterns in `bitfield-bitint-abi-align16.c` and `bitfield-bitint-abi-align8.c` have been updated to account for the asf tra

Re: [PATCH] sanitizer: Store no_sanitize attribute value in uint32 instead of unsigned

On April 22, 2025 12:08:51 AM PDT, Sam James wrote: >Kees Cook writes: > >> On Thu, Apr 10, 2025 at 05:17:51PM -0700, Keith Packard wrote: >>> A target using 16-bit ints won't have enough bits to hold the whole >>> flag_sanitize set. Be explicit about using uint32 for the attribute data. >>>

[PATCH] [14] Use --param=aarch64-autovec-preference=2 instead of =sve-only

This updates the backported test. Pushed. PR tree-optimization/119706 * g++.target/aarch64/sve/pr119706.C: Adjust --param aarch64-autovec-preference. --- gcc/testsuite/g++.target/aarch64/sve/pr119706.C | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: Ping: [RFA, GCC 15] testsuite: XFAIL predcom-8.c on aarch64 [PR118407]

On Tue, 22 Apr 2025, Richard Sandiford wrote: > Ping, since it sounds from irc like the release is coming soon :) Fine with me. > Richard Sandiford writes: > > gcc.dg/tree-ssa/predcom-8.c fails on aarch64 for the reasons discussed > > in the PR trail. The fix didn't make it into GCC 15, so thi

[PATCH] aarch64: Update FP8 dependencies for -mcpu=olympus

Hi all, We had not noticed that after g:299a8e2dc667e795991bc439d2cad5ea5bd379e2 the FP8FMA and FP8DOT4 features aren't implied by FP8FMA. The intent is for -mcpu=olympus to support all of them. Fix the definition to include the relevant sub-features explicitly. Bootstrapped and tested on aarch64

Re: [PATCH] aarch64: Update FP8 dependencies for -mcpu=olympus

On Tue, Apr 22, 2025 at 3:54 PM Kyrylo Tkachov wrote: > > Hi all, > > We had not noticed that after g:299a8e2dc667e795991bc439d2cad5ea5bd379e2 the > FP8FMA and FP8DOT4 features aren't implied by FP8FMA. The intent is for > -mcpu=olympus to support all of them. > Fix the definition to include the r

Re: [PATCH] asf: Enable pass at O2 or higher

On Wed, Jan 29, 2025 at 10:33:14AM +0100, Christoph Müllner wrote: > The avoid-store-forwarding pass is disabled by default and therefore > in the risk of bit-rotting. This patch addresses this by enabling > the pass at O2 or higher. > > The assembly patterns in `bitfield-bitint-abi-align16.c` an

[PATCH 0/3] A fix fixes for match and fold_stmt

I noticed while improving forwprop, that fold_stmt sometimes would return true even if there was no change that happened. These fixes 3 of those places. In the first one we had: ``` tmp = a ? b : c if (tmp != 0) ``` And match and simplify would return the same thing but that was just because of t

[PATCH 1/3] match: Move `(cmp (cond @0 @1 @2) @3)` simplification after the bool compare simplifcation

This moves the `(cmp (cond @0 @1 @2) @3)` simplifcation to be after the boolean comparison simplifcations so that we don't end up simplifing into the same thing for a GIMPLE_COND. gcc/ChangeLog: * match.pd: Move `(cmp (cond @0 @1 @2) @3)` simplifcation after the bool comparison

[PATCH 2/3] gimple-fold: Return early for GIMPLE_COND with true/false

To speed up things slightly so not needing to call all the way through to match and simplify, we should return early for true/false on GIMPLE_COND. gcc/ChangeLog: * gimple-fold.cc (fold_stmt_1): For GIMPLE_COND return early for true/false. Signed-off-by: Andrew Pinski --- gcc/g

[PATCH 3/3] gimple-fold: Don't replace `bool_var != 0` with `bool_var` inside GIMPLE_COND

Since match and simplify will simplify `bool_var != 0` to just `bool_var` and this is inside a GIMPLE_COND, fold_stmt will return true but nothing has changed. So let's just reject the replacement if we are replacing with the same simplification inside replace_stmt_with_simplification. This can s

Re: [patch fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

On Fri, Apr 18, 2025 at 05:48:46PM -0700, Jerry D wrote: > I will be committing a fix for this to the 16 mainline tonight. > > I am requesting Release Manager approval to push to 15 release branch after > full testing here. > > Regards, > > Jerry > > See attached diff. > > 2025-04-18 Steven G

Re: [PATCH 2/2] libstdc++: Define __cpp_lib_format_ranges in format header [PR109162]

On Tue, 22 Apr 2025 at 13:53, Tomasz Kamiński wrote: > > As P2286R8 and P2585R1 as now fully implemented, we now define > __cpp_lib_format_ranges feature test macro with __cpp_lib_format_ranges. > This macro is provided only in . > > Uses of internal __glibcxx_format_ranges are also updated. > >

Re: [PATCH] libphobos: enable for sparc64-unknown-linux-gnu

Excerpts from Sam James's message of April 20, 2025 2:46 am: > This bootstraps with some test failures but works well enough to build > 11..15. > > libphobos/ChangeLog: > > * configure.tgt: Add sparc64-unknown-linux-gnu as a supported target. > --- > As discussed on IRC. OK? I'd like to bac

Re: [GCC16,RFC,V2 03/14] aarch64: add new insn definition for st2g

On 4/15/25 9:21 AM, Richard Sandiford wrote: Indu Bhagat writes: Store Allocation Tags (st2g) is an Armv8.5-A memory tagging (MTE) instruction. It stores an allocation tag to two tag granules of memory. TBD: - Not too sure what is the best way to generate the st2g yet; A subsequent pat

Re: [GCC16,RFC,V2 02/14] aarch64: add new define_insn for subg

On 4/15/25 8:35 AM, Richard Sandiford wrote: Hi, Indu Bhagat writes: subg (Subtract with Tag) is an Armv8.5-A memory tagging (MTE) instruction. It can be used to subtract an immediate value scaled by the tag granule from the address in the source register. gcc/ChangeLog: * config/aa

Re: [PATCH] libstdc++: fix possible undefined atomic lock-free type aliases in module std

On Sun, 20 Apr 2025 at 10:03, ZENG Hao wrote: > > When building for 'i386-*' targets, all basic types are 'sometimes lock-free' > and thus std::atomic_signed_lock_free and std::atomic_unsigned_lock_free are > not declared. In the header , they are placed in preprocessor > condition __cpp_lib_atomic

Re: [GCC16,RFC,V2 04/14] aarch64: add new definition for post-index st2g

On 4/15/25 11:52 AM, Richard Sandiford wrote: Indu Bhagat writes: Using post-index st2g is a faster way of memory tagging/untagging. Because a post-index 'st2g tag, [addr], #32' is equivalent to: stg tag, addr, #0 stg tag, addr, #16 add addr, addr, #32 TBD: - Currently generated

[PATCH] testsuite: AMDGCN test for vect-early-break_38.c as well to consistent architecture [PR119286]

Hi All, I had missed this one during the AMDGCN test failures. Like vect-early-break_18.c this test is also scalaring the loads and thus leading to unexpected vectorization for this testcase. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Cross checked the failing case on amdgc

[PATCH] GCN: Properly switch sections in 'gcn_hsa_declare_function_name' [PR119737]

From: Andrew Pinski There are GCN/C++ target as well as offloading codes, where the hard-coded section names in 'gcn_hsa_declare_function_name' do not fit, and assembly thus fails: LLVM ERROR: Size expression must be absolute. This commit progresses GCN target: [-FAIL: g++.dg/init/call

  1   2   >