[PATCH][v2] tree-optimization/117912 - bogus address equivalences for __builtin_object_size

VN again is the culprit for exploiting address equivalences before __builtin_object_size got the chance to do its job. This time it isn't about union members but adjacent structure fields where an address to one after the last element of an array field can spill over to the next field. The follow

Re: [RFC/RFA][PATCH v7 00/12] CRC optimization.

Thank you all very much for your help! ) Mariam On Tue, Dec 10, 2024, 04:04 Jeff Law wrote: > > > On 12/9/24 3:43 PM, Richard Sandiford wrote: > > >> Thanks. I was just about to reach out to confirm we're OK on aarch64. > >> I was going to run everything through one of the cfarm machines or >

[r15-6063 Regression] FAIL: g++.dg/cpp0x/trivial1.C -std=c++26 (test for excess errors) on Linux/x86_64

On Linux/x86_64, 6c41a912f5e654a1b6f7cf8d6b23f00d8612988c is the first bad commit commit 6c41a912f5e654a1b6f7cf8d6b23f00d8612988c Author: Giuseppe D'Angelo Date: Mon Dec 9 01:28:08 2024 +0100 libstdc++: deprecate is_trivial for C++26 (P3247R2) caused FAIL: g++.dg/cpp0x/trivial1.C -std=c

Re: [PATCH] SVE intrinsics: Fold svmul and svdiv by -1 to svneg for unsigned types

Ping. Thanks, Jennifer > On 3 Dec 2024, at 09:14, Jennifer Schmitz wrote: > > Ping. > Thanks, > Jennifer > >> On 26 Nov 2024, at 09:18, Jennifer Schmitz wrote: >> >> >> >>> On 20 Nov 2024, at 13:43, Richard Sandiford >>> wrote: >>> >>> External email: Use caution opening links or attachm

[r15-6060 Regression] FAIL: g++.dg/warn/uninit-pr105562.C -std=gnu++26 (test for excess errors) on Linux/x86_64

On Linux/x86_64, e4a0157c2397c9b582cff71d114240a6b083a3dc is the first bad commit commit e4a0157c2397c9b582cff71d114240a6b083a3dc Author: Giuseppe D'Angelo Date: Mon Dec 9 02:11:19 2024 +0100 libstdc++: port bitwise relocatable away from is_trivial caused FAIL: g++.dg/warn/uninit-pr10556

[PATCH v1] Match: Refactor the signed SAT_ADD match patterns [NFC]

From: Pan Li This patch would like to refactor the all signed SAT_ADD patterns, aka: * Extract type check outside. * Re-arrange the related match pattern forms together. The below test suites are passed for this patch. * The rv64gcv fully regression test. * The x86 bootstrap test. * The x86 full

[PATCH v5 08/10] OpenMP: Fortran support for metadirectives and dynamic selectors

gcc/fortran/ChangeLog PR middle-end/112779 PR middle-end/113904 * decl.cc (gfc_match_end): Handle COMP_OMP_BEGIN_METADIRECTIVE and COMP_OMP_METADRIECTIVE. * dump-parse-tree.cc (show_omp_node): Handle EXEC_OMP_METADIRECTIVE. (show_code_node): Likewise.

[PATCH v5 06/10] OpenMP: C++ support for metadirectives and dynamic selectors.

Additional shared C/C++ testcases are included in a subsequent patch in this series. gcc/cp/ChangeLog PR middle-end/112779 PR middle-end/113904 * cp-tree.h (struct saved_scope): Add new field x_processing_omp_trait_property_expr. (processing_omp_trait_proper

[PATCH v5 09/10] OpenMP: Update "declare target"/OpenMP context interaction

The code and test case previously implemented the OpenMP 5.0 spec, which said in section 2.3.1: "For functions within a declare target block, the target trait is added to the beginning of the set..." In OpenMP 5.1, this was changed to "For device routines, the target trait is added to the beginni

[PATCH v5 05/10] OpenMP: Add C support for metadirectives and dynamic selectors.

Additional shared C/C++ testcases are included in a subsequent patch in this series. gcc/c-family/ChangeLog PR middle-end/112779 PR middle-end/113904 * c-common.h (enum c_omp_directive_kind): Add C_OMP_DIR_META. (c_omp_expand_variant_construct): Declare. * c

[PATCH v5 10/10] OpenMP: Update documentation of metadirective implementation status.

libgomp/ChangeLog * libgomp.texi (OpenMP 5.0): Mark metadirective and declare variant as implemented. (OpenMP 5.1): Mark target_device as supported. Add changed interaction between declare target and OpenMP context and dynamic selector support. (OpenM

[PATCH v5 07/10] OpenMP: Shared metadirective/dynamic selector tests for C and C++

gcc/testsuite/ChangeLog * c-c++-common/gomp/attrs-metadirective-1.c: New. * c-c++-common/gomp/attrs-metadirective-2.c: New. * c-c++-common/gomp/attrs-metadirective-3.c: New. * c-c++-common/gomp/attrs-metadirective-4.c: New. * c-c++-common/gomp/attrs-metadirec

[PATCH v5 03/10] OpenMP: Remove dead code from declare variant reimplementation

After reimplementing late resolution of "declare variant", the declare_variant_alt and calls_declare_variant_alt flags on struct cgraph_node are no longer used by anything. For the purposes of marking functions that need late resolution, the has_omp_variant_constructs flag has replaced calls_decla

[PATCH v5 02/10] OpenMP: Re-work and extend context selector resolution

This patch reimplements the middle-end support for "declare variant" and extends the resolution mechanism to also handle metadirectives (PR112779). It also adds partial support for dynamic selectors (PR113904) and fixes a selector scoring bug reported as PR114596. I hope this rewrite also improve

[PATCH v5 04/10] OpenMP: Robustify C front end handling of attribute-syntax pragmas

Presently, the code to handle OpenMP attribute-syntax pragmas in the C front end assumes nothing else is messing with redirecting parser->tokens, and makes no provision for restoring it from anything other than parser->tokens_buf when the buffer allocated for the pragma is exhausted. Adding suppor

[PATCH v5 00/10] OpenMP: Implement metadirective and dynamic selectors

I realized last week that the previous version of this patch series that I posted on Nov 15: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669053.html collided with Paul-Antoine's "dispatch" construct patches that were pushed a few days later, and no longer applied cleanly. I've prepar

[PATCH v5 01/10] OpenMP: New tree nodes for metadirective and dynamic selector support.

This patch adds basic support for three new tree node types that will be used in subsequent patches to support OpenMP metadirectives and dynamic selectors. OMP_METADIRECTIVE is the internal representation of parsed OpenMP metadirective constructs. It's produced by the front ends and is expanded d

[patch, libgfortran] Bug 117819 - Formatted READ with BZ in format fails

Hi all, The attached patch fixes this bug by checking for the case of a short READ that should be padded with blanks and if the BZ mode is enabled, those blanks should be treated as trailing zero's. New test case courtesy Malcom Cohen. Regression tested on X86_64_linux_gnu. OK for trunk and

[PATCH V2] Fix inaccuracy in cunroll/cunrolli when considering what's innermost loop.

> Please pass 'sbitmap' instead of auto_sbitmap&, it should properly > decay to that.  Applies everywhere I think. > Changed. > In fact I wonder whether we should simply populate the bitmap > from a > > for (auto loop : loops_list (cfun, LI_ONLY_INNERMOST)) > bitmap_set_bit (original_innerm

Re: [PATCH] c++, coroutines: Make suspend index consistent for debug.

On 12/9/24 2:39 PM, Iain Sandoe wrote: On 9 Dec 2024, at 19:34, Jason Merrill wrote: On 12/9/24 2:00 PM, Iain Sandoe wrote: On 9 Dec 2024, at 18:56, Jason Merrill wrote: On 11/29/24 8:47 AM, Iain Sandoe wrote: Tested on x86_64-darwin, x86_64-linux, OK for trunk? thanks Iain --- 8< --- At

Re: [PATCH v3] Re: libstdc++: use is_virtual_base_of in std::weak_ptr operations

Hello, On 04/12/2024 13:20, Giuseppe D'Angelo wrote: Thank you for the review! I think I've incorporated all the changes, new patch is attached. Some other comments... By doing some more testing, I've noticed that this patch causes a build issue when a weak_ptr is used to construct a weak_pt

[PATCH] libstdc++: fix compile error when converting std::weak_ptr

Hello, The attached patch fixes a compile error when converting a weak_ptr of array type to a compatible type, for instance: std::weak_ptr wptr; std::weak_ptr wptr2 = wptr; // ERROR https://gcc.godbolt.org/z/EWYb73Mvf The reason seems to be a typo: the inner __weak_ptr class has a lock() im

Re: [PATCH v3] c++: P2865R5, Remove Deprecated Array Comparisons from C++26 [PR117788]

On 12/9/24 6:32 PM, Marek Polacek wrote: On Fri, Dec 06, 2024 at 12:48:35PM -0500, Jason Merrill wrote: On 12/6/24 12:29 PM, Marek Polacek wrote: On Thu, Dec 05, 2024 at 01:15:49PM -0500, Jason Merrill wrote: On 12/4/24 12:27 PM, Marek Polacek wrote: On Tue, Dec 03, 2024 at 04:27:22PM -0500,

Re: [PATCH v3] c++, coroutines: Fix awaiter var creation [PR116506].

On 12/9/24 1:52 PM, Iain Sandoe wrote: On 9 Dec 2024, at 17:41, Jason Merrill wrote: On 10/31/24 4:40 AM, Iain Sandoe wrote: This version tested on x86_64-darwin,linux, powerpc64-linux, on folly and by Sam on wider codebases, Why don't you need a variable to preserve o across suspensions i

Re: [PATCH 6/6 v2] libstdc++: deprecate is_trivial (P3247R2)

On Mon, 9 Dec 2024 at 20:34, Giuseppe D'Angelo wrote: > > On 09/12/2024 18:43, Jonathan Wakely wrote: > > On Mon, 9 Dec 2024 at 13:49, Jonathan Wakely wrote: > >> On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote: > >>> Hello, > >>> > >>> This ports some misc test away from is_trivial. > >> This is

Re: [RFC/RFA][PATCH v7 00/12] CRC optimization.

On 12/9/24 3:43 PM, Richard Sandiford wrote: Thanks. I was just about to reach out to confirm we're OK on aarch64. I was going to run everything through one of the cfarm machines or perhaps my rpi as a final test. Ah, yeah. I'm hopelessly behind on gcc-patches, so hadn't seen that you wer

[PATCH v3] c++: P2865R5, Remove Deprecated Array Comparisons from C++26 [PR117788]

On Fri, Dec 06, 2024 at 12:48:35PM -0500, Jason Merrill wrote: > On 12/6/24 12:29 PM, Marek Polacek wrote: > > On Thu, Dec 05, 2024 at 01:15:49PM -0500, Jason Merrill wrote: > > > On 12/4/24 12:27 PM, Marek Polacek wrote: > > > > On Tue, Dec 03, 2024 at 04:27:22PM -0500, Jason Merrill wrote: > > >

[PATCH] c++: ICE with -Wduplicated-branches in template [PR117880]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14? -- >8 -- In a template, for things like void() we'll create a CAST_EXPR with a null operand. That causes a crash with -Wduplicated-branches on: false ? void() : void(); because we do if (warn_duplicated_branches && (comp

Re: [PATCH] aarch64: Remove vcond{,u} optabs

On Mon, Dec 9, 2024 at 3:02 PM Richard Sandiford wrote: > > Prompted by Richard E's arm patch, this one removes the aarch64 > support for the vcond{,u} optabs. > > Tested on aarch64-linux-gnu. I'll push tomorrow if there are no > objections. There might still be some fallout from the transition

[PATCH] Remove vcond{,u,eq} optabs

This patch removes the remaining traces of the vcond{,u,eq} optabs. Earlier patches removed the target-independent uses and I couldn't find any direct references to either the *_optabs or the ifns in target-specific code. Tested on aarch64-linux-gnu. OK to install? Richard gcc/ * doc/m

[PATCH] aarch64: Remove vcond{,u} optabs

Prompted by Richard E's arm patch, this one removes the aarch64 support for the vcond{,u} optabs. Tested on aarch64-linux-gnu. I'll push tomorrow if there are no objections. There might still be some fallout from the transition that we need to fix (haven't checked yet), but this code wouldn't fo

Re: [RFC/RFA][PATCH v7 00/12] CRC optimization.

Jeff Law writes: > On 12/9/24 10:00 AM, Richard Sandiford wrote: >> Mariam Arutunian writes: >>> Hello, >>> >>> This patch series is a revised version of the following: >>> https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668229.html. >>> >>> In this version: >>> >>> - Patch 09/12 has

Re: [PATCH v3 1/7] middle-end: Handle resized PHI nodes in loop_version()

On Mon, Dec 09, 2024 at 02:07:07PM +0100, Richard Biener wrote: > On Tue, Dec 3, 2024 at 2:42 PM Richard Biener > wrote: > > > > On Tue, Dec 3, 2024 at 2:07 PM Lewis Hyatt wrote: > > > > > > On Tue, Dec 03, 2024 at 01:28:28PM +0100, Richard Biener wrote: > > > > On Mon, Dec 2, 2024 at 1:55 AM Lew

Re: [PATCH v6 2/7] Drop targetm.promote_prototypes from C, C++ and Ada frontends

On Tue, Dec 10, 2024, 5:31 AM Joseph Myers wrote: > On Fri, 6 Dec 2024, Richard Biener wrote: > > > On Wed, Dec 4, 2024 at 9:48 PM H.J. Lu wrote: > > > > > > Remove the targetm.calls.promote_prototypes call from C, C++ and Ada > > > frontends. > > > > I'm conditionally approving this unless FE m

Re: [PATCH] driver: fix crash with --diagnostics-plain-output [PR117942]

On Mon, 9 Dec 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > We are crashing here because decode_cmdline_options_to_array has: > > if (!strcmp (opt, "-fdiagnostics-plain-output")) > ... > > but that doesn't handle the '--FLAG' vari

Re: [PATCH v6 2/7] Drop targetm.promote_prototypes from C, C++ and Ada frontends

On Fri, 6 Dec 2024, Richard Biener wrote: > On Wed, Dec 4, 2024 at 9:48 PM H.J. Lu wrote: > > > > Remove the targetm.calls.promote_prototypes call from C, C++ and Ada > > frontends. > > I'm conditionally approving this unless FE maintainers complain before > holidays > (the effect of the hook i

[PATCH v4] 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, fix the constant (any non-zero value is converted to all 1s) and emit a warning. On MVE, V8

Re: [PATCH] config: nvptx: fix bashisms with gen-copyright.sh use

On Fri, 6 Dec 2024, Thomas Schwinge wrote: > First: Tom, what was your original intention why we'd keep the generated > files in the sources? (..., instead of just generating them at build > time, like 'gcc/config/nvptx/t-omp-device' does for > 'omp-device-properties-nvptx', for example. In that

[PATCH] libstdc++: Skip redundant assertions in std::array equality [PR106212]

As PR c++/106212 shows, the Debug Mode checks cause a compilation error for equality comparisons involving std::array prvalues in constant expressions. Those Debug Mode checks are redundant when comparing two std::array objects, because we already know we have a valid range. We can also avoid the u

Re: [PATCH 6/6 v2] libstdc++: deprecate is_trivial (P3247R2)

On 09/12/2024 18:43, Jonathan Wakely wrote: On Mon, 9 Dec 2024 at 13:49, Jonathan Wakely wrote: On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote: Hello, This ports some misc test away from is_trivial. This is fine, thanks. I'm seeing a number of FAILures not fixed by this patch: Apologies,

Re: [PATCH] wwwdocs: gcc-15: start adding notes on C23

On Mon, Dec 09, 2024 at 02:44:42PM -0500, David Malcolm wrote: > +C23 brings the following changes: > + > +Function prototypes with empty > params change from implicit int to void > + > + In C23 () in a function declaration means the same as > (void), whereas previously it implicitly declared the

[PATCH v4] fold fold_truth_andor field merging into ifcombine

This patch introduces various improvements to the logic that merges field compares, while moving it into ifcombine. Before the patch, we could merge: (a.x1 EQNE b.x1) ANDOR (a.y1 EQNE b.y1) into something like: (((type *)&a)[Na] & MASK) EQNE (((type *)&b)[Nb] & MASK) if both of A's field

[PATCH] wwwdocs: gcc-15: start adding notes on C23

How does this look? Thanks Dave --- htdocs/gcc-15/changes.html| 12 htdocs/gcc-15/porting_to.html | 34 +- 2 files changed, 45 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html index 23866bde..94731

[PATCH] driver: fix crash with --diagnostics-plain-output [PR117942]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- We are crashing here because decode_cmdline_options_to_array has: if (!strcmp (opt, "-fdiagnostics-plain-output")) ... but that doesn't handle the '--FLAG' variant. gcc/ChangeLog: * opts-common.cc (decode_cmdli

Re: [PATCH] c++, coroutines: Make suspend index consistent for debug.

> On 9 Dec 2024, at 19:34, Jason Merrill wrote: > > On 12/9/24 2:00 PM, Iain Sandoe wrote: >>> On 9 Dec 2024, at 18:56, Jason Merrill wrote: >>> >>> On 11/29/24 8:47 AM, Iain Sandoe wrote: Tested on x86_64-darwin, x86_64-linux, OK for trunk? thanks Iain --- 8< --- >>

[PATCH] testsuite/gcc.dg/tree-ssa/pr117973-1.c: New test

I could probably assume that this is what you had in mind, but anyway: Ok to commit? -- >8 -- PR117973 covers the aspect of non-LOGICAL_OP_NON_SHORT_CIRCUIT targets for PR111456, for which the test-case gcc.dg/tree-ssa/pr111456-1.c started failing as described in PR117954. * gcc.dg/tree-s

[PATCH v3] testsuite/gcc.dg/tree-ssa/pr111456-1.c: Handle fallout

> From: Richard Biener > Date: Mon, 9 Dec 2024 10:06:49 +0100 > As Andrew said the fix the testcase was written for was targeting > --param logical-op-non-short-circuit=1 it makes more sense to force > that so we continue to check it works. 'k, that's a valid argument. > We should simply track

Re: [PATCH] c++, coroutines: Make suspend index consistent for debug.

On 12/9/24 2:00 PM, Iain Sandoe wrote: On 9 Dec 2024, at 18:56, Jason Merrill wrote: On 11/29/24 8:47 AM, Iain Sandoe wrote: Tested on x86_64-darwin, x86_64-linux, OK for trunk? thanks Iain --- 8< --- At present, we only update the suspend index when we actually are at the stage that the co

[PATCH] replace atoi with strtoul in opts.cc, lto-wrapper.c, lto/lto.c [PR114542]

Straight forward replacements of atoi() with strtoul() in order to avoid UB and detect invalid argument values. Tested with x86_64-pc-linux-gnu. 2024-12-09 Heiko Eißfeldt     PR lto/114542     * lto-wrapper.cc (run_gcc):     Use strtoul with ERANGE check instead of atoi     * lto/lto.cc (do_wh

Re: [PATCH] c++, coroutines: Handle statement expressions part 1.

On 11/29/24 8:43 AM, Iain Sandoe wrote: Tested on x86_64-darwin, x86_64/powerpc64-linux, on folly and more widely by Sam. There are possibly additional BZ dups that will be covered (this fixes 117231, a P1). OK for trunk? thanks Iain --- 8< --- In the current implementation, statement expressi

Re: [PATCH] c++, coroutines: Make suspend index consistent for debug.

> On 9 Dec 2024, at 18:56, Jason Merrill wrote: > > On 11/29/24 8:47 AM, Iain Sandoe wrote: >> Tested on x86_64-darwin, x86_64-linux, >> OK for trunk? >> thanks >> Iain >> --- 8< --- >> At present, we only update the suspend index when we actually are >> at the stage that the coroutine is cons

Re: [PATCH] c++, coroutines:Ensure bind exprs are visited once [PR98935].

On 11/29/24 8:45 AM, Iain Sandoe wrote: Tested on x86_64-darwin, x86_64, powerpc64-linux, OK for trunk? thanks Iain --- 8< --- Recent changes in the C++ FE and the coroutines implementation have exposed a latent issue in which a bind expression containing a var that we need to capture in the co

Re: [PATCH] c++, coroutines: Make suspend index consistent for debug.

On 11/29/24 8:47 AM, Iain Sandoe wrote: Tested on x86_64-darwin, x86_64-linux, OK for trunk? thanks Iain --- 8< --- At present, we only update the suspend index when we actually are at the stage that the coroutine is considered suspended. This is on the basis that it is UB to resume or destroy

Re: [PATCH v3] c++, coroutines: Fix awaiter var creation [PR116506].

> On 9 Dec 2024, at 17:41, Jason Merrill wrote: > > On 10/31/24 4:40 AM, Iain Sandoe wrote: >> This version tested on x86_64-darwin,linux, powerpc64-linux, on folly >> and by Sam on wider codebases, > Why don't you need a variable to preserve o across suspensions if it's a > call retu

Re: [PATCH 5/6] libstdc++: port tests away from is_trivial

On Mon, 9 Dec 2024 at 17:44, Jonathan Wakely wrote: > > On Mon, 9 Dec 2024 at 17:43, Jonathan Wakely wrote: > > > > On Mon, 9 Dec 2024 at 13:49, Jonathan Wakely wrote: > > > > > > On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote: > > > >Hello, > > > > > > > >This ports some misc test away from is

[PATCH 2/3] testsuite: RISC-V: Explicitly specify ABI when passing -mcpu=

The tests are specifying -mcpu=, but do not explicitly define an ABI. Thus the test spuriously fail when the toolchain has been built for RV32E. Fix by adding the necessary markings. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr109508.c: Pass -mabi=lp64d option. * gcc.target/ris

Re: [PATCH 5/6] libstdc++: port tests away from is_trivial

On Mon, 9 Dec 2024 at 13:49, Jonathan Wakely wrote: > > On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote: > >Hello, > > > >This ports some misc test away from is_trivial. > > This is fine, thanks. I'm seeing a number of FAILures not fixed by this patch: FAIL: experimental/iterator/requirements.cc

[PATCH] libstdc++: Skip redundant assertions in std::span construction [PR117966]

As PR c++/117966 shows, the Debug Mode checks cause a compilation error for a global constexpr std::span. Those checks are redundant when constructing from an array or a range, because we already know we have a valid range and we know its size. Instead of delegating to the std::span(contiguous_iter

Re: [PATCH 5/6] libstdc++: port tests away from is_trivial

On Mon, 9 Dec 2024 at 17:43, Jonathan Wakely wrote: > > On Mon, 9 Dec 2024 at 13:49, Jonathan Wakely wrote: > > > > On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote: > > >Hello, > > > > > >This ports some misc test away from is_trivial. > > > > This is fine, thanks. > > I'm seeing a number of FAIL

Re: [PATCH v3] c++, coroutines: Fix awaiter var creation [PR116506].

On 10/31/24 4:40 AM, Iain Sandoe wrote: This version tested on x86_64-darwin,linux, powerpc64-linux, on folly and by Sam on wider codebases, Why don't you need a variable to preserve o across suspensions if it's a call returning lvalue reference? We always need a space for the awaiter, unless

Re: [PATCH 1/3] testsuite: RISC-V: Explicitly specify ABI when adding V and Zvbb options

On Mon, 09 Dec 2024 09:05:10 PST (-0800), Robin Dapp wrote: +/* { dg-additional-options "-mabi=lp64d" { target { rv64 } } } */ +/* { dg-additional-options "-mabi=ilp32d" { target { rv32 } } } */ Wouldn't skipping those tests also be reasonable? I.e. adding a target to the compile directive inst

Re: [PATCH] Fortran: fix two minor front-end GMP memleaks

Thanks, Jerry! Pushed as r15-6053. Am 08.12.24 um 23:57 schrieb Jerry Delisle: Looks good, OK to push. On Sun, Dec 8, 2024, 1:39 PM Harald Anlauf wrote: Dear all, while looking at testcases with inquiry refs, I encountered two minor GMP memleaks due to double-initialization of GMP variable

Re: [PATCH] expr: Don't clear whole unions [PR116416]

On Sat, Dec 07, 2024 at 10:01:53AM -0500, Jason Merrill wrote: > On 12/6/24 5:02 PM, Marek Polacek wrote: > > On Mon, Oct 14, 2024 at 03:57:45PM -0400, Jason Merrill wrote: > > > OK. > > > > The patch was approved, but even after the r15-5746 + r15-5747 changes, > > pr78687.C still FAILs: > >

Re: [RFC/RFA][PATCH v7 00/12] CRC optimization.

On 12/9/24 10:00 AM, Richard Sandiford wrote: Mariam Arutunian writes: Hello, This patch series is a revised version of the following: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668229.html. In this version: - Patch 09/12 has been updated with comments provided by Matevos

Re: [PATCH 1/3] testsuite: RISC-V: Explicitly specify ABI when adding V and Zvbb options

> +/* { dg-additional-options "-mabi=lp64d" { target { rv64 } } } */ > +/* { dg-additional-options "-mabi=ilp32d" { target { rv32 } } } */ Wouldn't skipping those tests also be reasonable? I.e. adding a target to the compile directive instead. I'd find that a bit more intuitive than overriding th

Re: [RFC/RFA][PATCH v7 00/12] CRC optimization.

Mariam Arutunian writes: > Hello, > > This patch series is a revised version of the following: > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668229.html. > > In this version: > >- Patch 09/12 has been updated with comments provided by Matevos, which >were missing in the previou

Re: [PATCH] clang-format AlwaysBreakAfterReturnType to TopLevelDefinitions

On 12/9/24 9:36 AM, mmalcom...@nvidia.com wrote: From: Matthew Malcomson The previous value of TopLevel meant that the function name of declarations would also be on a new line. This does not match the current formatting of headers. Manual testing done on c-common.h. Also set BraceWrapping.B

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

On 06/12/2024 18:14, Christophe Lyon wrote: On Fri, 6 Dec 2024 at 12:41, Richard Earnshaw (lists) wrote: On 04/12/2024 20:56, Christophe Lyon wrote: On Wed, 4 Dec 2024 at 12:39, Richard Earnshaw (lists) wrote: On 25/11/2024 20:08, Christophe Lyon wrote: In this PR, we have to handle a cas

Re: [PATCH 0/3] testsuite: RISC-V: Improve support for RV32E

Oh i just saw other part before i saw cover letter, anyway， LGTM for this patch set, thanks :) Dimitar Dimitrov 於 2024年12月10日 週二 00:16 寫道： > Many test cases implicitly require some form of I ABI variant for > RISC-V to be the default. Hence they fail when ILP32E is configured as > the default A

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

> On Dec 7, 2024, at 03:57, Martin Uecker wrote: > > Am Freitag, dem 06.12.2024 um 16:13 + schrieb Qing Zhao: >> >>> On Dec 6, 2024, at 10:56, Martin Uecker wrote: >>> >>> Am Freitag, dem 06.12.2024 um 14:16 + schrieb Qing Zhao: > > ... > > > I think the relevant sce

[PATCH] libstdc++: Fix fancy pointer support in linked lists

The union members I used in the new _Node types for fancy pointers only work for value types that are trivially default constructible. This change adds an unsigned char member to the union, so the node's default constructor is not defined as deleted. libstdc++-v3/ChangeLog: * include/bits

[PATCH 1/3] testsuite: RISC-V: Explicitly specify ABI when adding V and Zvbb options

Some tests add options for V and Zvbb extensions, but do not have checks whether the default abi supports them. Fix by explicitly specifying ilp32d and lp64d ABI. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/binop/vandn-1.c: Specify ilp32d ABI for RV32 targets, and lp6

[PATCH 0/3] testsuite: RISC-V: Improve support for RV32E

Many test cases implicitly require some form of I ABI variant for RISC-V to be the default. Hence they fail when ILP32E is configured as the default ABI for the toolchain. Example error: spawn ... -march=rv32gc_zbb ... cc1: error: ILP32E ABI does not support the 'D' extension This p

[committed v2] libstdc++: Add workaround for read(2) EINVAL on macOS and FreeBSD [PR102259]

On macOS and FreeBSD the read(2) system call can return EINVAL for large sizes, so limit the maximum that we try to read. The calling code in basic_filebuf::xsgetn will loop until it gets the size it wants, so we don't need to loop in basic_file::xsgetn, just limit the maximum size. libstdc++-v3/C

Re: [PATCH v2] gimple: Add limit after which slower switchlower algs are used [PR117091] [PR117352]

> Am 09.12.2024 um 16:19 schrieb Filip Kastl : > > Hi Richi, > > This is the second version of the patch. I've lowered the default value of > the > switch-lower-slow-alg-max-cases from 1 to 1000. I've also noticed that I > forgot to add an entry into the param section of doc/invoke.tex

[committed] libstdc++: Remove std::allocator::is_always_equal typedef for C++26

This was removed by P2868R3, voted into the C++26 draft at the November 2023 meeting in Kona. We've had a deprecated warning in place for three years. libstdc++-v3/ChangeLog: * include/bits/allocator.h (allocator::is_always_equal): Do not define for C++26. (allocator::is_a

RE: [PATCH 6/7]middle-end: add vec_init support for variable length subvector concatenation.

> >> So I think we can simply set const_n_elts to CONSTRUCTOR_NELTS > >> for vector_typed_elts_p? > >> > > Done, gcc/ChangeLog: PR target/96342 * expr.cc (store_constructor): add support for variable-length vectors. Co-authored-by: Tamar Christina Bootstrapped Regteste

[PATCH v2 2/4] arm: [MVE intrinsics] add support for tuples

This patch is largely a copy/paste from the aarch64 SVE counterpart, and adds support for tuples to the MVE intrinsics framework. Introduce function_resolver::infer_tuple_type which will be used to resolve overloaded vst2q and vst4q function names in a later patch. Fix access to acle_vector_types

[PATCH v2] gimple: Add limit after which slower switchlower algs are used [PR117091] [PR117352]

Hi Richi, This is the second version of the patch. I've lowered the default value of the switch-lower-slow-alg-max-cases from 1 to 1000. I've also noticed that I forgot to add an entry into the param section of doc/invoke.texi so I fixed that. I'm bootstraping and regtesting this again just

Re: [PATCH 2/6] libstdc++: pstl: port away from is_trivial

On 09/12/2024 14:13, Jonathan Wakely wrote: Could I ask you to open an issue about std::is_trivial upstream: https://github.com/oneapi-src/oneDPL/issues If/when they fix it, we can consider aligning with their direction. And that might resolve the question of which aspects of triviality are real

[committed] libstdc++: Fix debug containers for constant evaluation [PR117962]

Using a stateful allocator with std::vector would fail in Debug Mode, because the allocator-extended move constructor tries to swap all the attached safe iterators, but that uses a non-inline function which isn't constexpr. We don't actually need to swap any iterators in constant expressions, becau

[PATCH v2 3/4] arm: [MVE intrinsics] fix store shape to support tuples

Now that tuples are properly supported, we can update the store shape, to expect "t0" instead of "v0" as last argument. gcc/ChangeLog: * config/arm/arm-mve-builtins-shapes.cc (struct store_def): Add support for tuples. --- gcc/config/arm/arm-mve-builtins-shapes.cc | 4 ++-- 1 fil

[PATCH v2 0/4] arm: [MVE intrinsics] Rework intrinsics for loads/stores/ tuples

Changes v1->v2: - Keep MAX_TUPLE_SIZE=0 and update accesses to acle_vector_types accordingly. - implement arm_array_mode in patch 4/4 instead of 2/4 to avoid temporary regressions when running the testsuite at patch 2/4 (helps future bisects) This patch series re-implements the intrinscs

[PATCH v2 4/4] arm: [MVE intrinsics] rework vst2q vst4q vld2q vld4q

Implement vst2q, vst4q, vld2q and vld4q using the new MVE builtins framework. Since MVE uses different tuple modes than Neon, we need to use VALID_MVE_STRUCT_MODE because VALID_NEON_STRUCT_MODE is no longer a super-set of it, for instance in output_move_neon and arm_print_operand_address. In arm_

[PATCH v2 1/4] arm: [MVE intrinsics] add modes for tuples

Add V2x and V4x modes, like we do on aarch64 for Advanced SIMD q-registers. gcc/ChangeLog: * config/arm/arm-modes.def (MVE_STRUCT_MODES): New. --- gcc/config/arm/arm-modes.def | 22 ++ 1 file changed, 22 insertions(+) diff --git a/gcc/config/arm/arm-modes.def b/gcc/c

[committed] RISC-V testsuite changes to test clmul expansion of CRCs

This testsuite only patch allows us to test code generation for CRC functions using clmul instructions. Conceptually it's trivial. We already have various execution tests in gcc.dg/torture. We just define a new set of dg directives and include the testcase in gcc.dg/torture. The only gotch

[PATCH] clang-format AlwaysBreakAfterReturnType to TopLevelDefinitions

From: Matthew Malcomson The previous value of TopLevel meant that the function name of declarations would also be on a new line. This does not match the current formatting of headers. Manual testing done on c-common.h. Also set BraceWrapping.BeforeWhile to true to match the formatting specifie

[patch] Allow target to chose address-space for artificial rodata lookup tables.

This patch adds a new target hook that allows to chose a non-generic named address-space for compiler generated lookup tables. The purpose is that there are cases (on avr namely) where the generic address space is sub-optimal because it must put .rodata in RAM. With this hook it is possible to c

Re: [PATCH] s390: Fix UNSPEC_CC_TO_INT canonicalization

On 12/6/24 19:00, Juergen Christ wrote: Canonicalization of comparisons for UNSPEC_CC_TO_INT missed one case causing unnecessarily complex code. This especially seems to hit the Linux kernel. gcc/ChangeLog: * config/s390/s390.cc (s390_canonicalize_comparison): Add missing UN

Re: [PATCH 5/6] libstdc++: port tests away from is_trivial

On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote: Hello, This ports some misc test away from is_trivial. This is fine, thanks. Thanks, -- Giuseppe D'Angelo From 7b0548ee8732b5211a50cba7781b4fe25d9f5f04 Mon Sep 17 00:00:00 2001 From: Giuseppe D'Angelo Date: Mon, 9 Dec 2024 02:44:30 +0100

Re: [PATCH] tree-optimization/117912 - bogus address equivalences for __builtin_object_size

On Mon, Dec 09, 2024 at 02:30:59PM +0100, Richard Biener wrote: > Those would be UB, I've tried to keep the check conservative but fast. Ok. > I'll retest, repost and push. thanks. Jakub

Re: [PATCH 6/6] libstdc++: deprecate is_trivial (P3247R2)

On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote: Hello, Finally, this commit deprecates is_trivial and is_trivial_v in C++26. Looks good, thanks. I'll apply this whole series. Thanks, -- Giuseppe D'Angelo From 976ad3ec85cdd6fbd6eea7495077ef5b602cf088 Mon Sep 17 00:00:00 2001 From: Giuse

Re: [PATCH 4/6] libstdc++: port the ranges::uninitialized_* algorithms away from is_trivial

On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote: Hello, The range-based uninitialized_* algorithm have codepaths that turn constructions into assignments if the output type is trivial. Change this detection to be more accurate. There's a couple of cases which are suspicious and deserve accur

Re: [PATCH] tree-optimization/117912 - bogus address equivalences for __builtin_object_size

On Mon, 9 Dec 2024, Jakub Jelinek wrote: > Hi! > > On Thu, Dec 05, 2024 at 11:37:45AM +0100, Richard Biener wrote: > > VN again is the culprit for exploiting address equivalences before > > __builtin_object_size got the chance to do its job. This time > > it isn't about union members but adjacen

Re: [PATCH 2/6] libstdc++: pstl: port away from is_trivial

On 09/12/24 13:13 +, Jonathan Wakely wrote: On 09/12/24 13:08 +0100, Giuseppe D'Angelo wrote: For PSTL, I've just chosen to port from is_trivial to the direct equivalent, as I'm really unsure about the meaning of the code. Yeah, I'm not sure either. I note that the code uses std::conjunct

Re: [PATCH 3/6] libstdc++: port bitwise relocatable away from is_trivial

On 09/12/24 13:22 +0100, Giuseppe D'Angelo wrote: Hello, This aligns __is_bitwise_relocatable with its modern meaning, that is, checking for trivial move construction and destruction. Looks good, thanks. Thanks, -- Giuseppe D'Angelo From 0666e993066818ab0940c61d8d9539e883848b29 Mon Sep 1

Re: [PATCH] Free RTL SSA after late-combine

Richard Biener writes: > Late-combine fails to release RTL SSA info, leaking memory > (as -fmem-report shows). Ouch! Pretty big blunder, sorry :( > Bootstrap and regtest running on x86_64-unknown-linux-gnu, OK? OK, thanks. Richard > > Thanks, > Richard. > > * late-combine.cc (late_comb

Re: [PATCH] docs: Clarify -fsanitize=hwaddress target support [PR117960]

On Mon, 9 Dec 2024, Jakub Jelinek wrote: > Hi! > > Since GCC 13 -fsanitize=hwaddress is not supported just on AArch64, but also > on x86_64 (but only with -mlam=u48 or -mlam=u57). > > Ok for trunk? OK. > 2024-12-09 Jakub Jelinek > > PR sanitize/117960 > * doc/invoke.texi (fsani

Re: [PATCH 2/6] libstdc++: pstl: port away from is_trivial

On 09/12/24 13:08 +0100, Giuseppe D'Angelo wrote: For PSTL, I've just chosen to port from is_trivial to the direct equivalent, as I'm really unsure about the meaning of the code. Yeah, I'm not sure either. I note that the code uses std::conjunction instead of the non-portable __and_. std::conj

[PATCH] Free RTL SSA after late-combine

Late-combine fails to release RTL SSA info, leaking memory (as -fmem-report shows). Bootstrap and regtest running on x86_64-unknown-linux-gnu, OK? Thanks, Richard. * late-combine.cc (late_combine::execute): Delete RTL SSA. --- gcc/late-combine.cc | 4 1 file changed, 4 insertions(+

  1   2   >