Re: [PATCH] c++/modules: Stream warning suppressions [PR115757]

On Tue, Jul 23, 2024 at 05:14:30PM -0400, Patrick Palka wrote: > On Tue, 23 Jul 2024, Jason Merrill wrote: > > > On 7/7/24 12:39 AM, Nathaniel Shead wrote: > > > Bootstrapped on x86_64-pc-linux-gnu, successfully regtested modules.exp; > > > OK for trunk if full regtest passes? > > > > Patrick, I

Re: [PATCH] c++/modules: Ensure deduction guides are always reachable [PR115231]

On Tue, Jul 23, 2024 at 04:17:22PM -0400, Jason Merrill wrote: > On 6/15/24 10:29 PM, Nathaniel Shead wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > This probably isn't the most efficient approach, since we need to do > > name lookup to find deduction guides

[PATCH 2/3] isel: Small cleanup of duplicating comparisons

This is a small cleanup of the duplicating comparison code. There is code generation difference but only for -O0 and -fno-tree-ter (both of which will be fixed in a later patch). The difference is instead of skipping the first use if the comparison uses are only in cond_expr we skip the last use.

[PATCH 1/3] isel: Move duplicate comparisons to its own function

This is just a small cleanup to isel and no functional changes just. The loop inside pass_gimple_isel::execute looked was getting too deap so let's fix that by moving it to its own function. Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: * gimple-isel.cc

[PATCH 3/3] isel: Don't duplicate comparisons for -O0 nor -fno-tree-ter [PR116101]

While doing cleanups on this code I noticed that we do the duplicate of comparisons at -O0. For C and C++ code this makes no difference as the gimplifier never produces COND_EXPR. But it could make a difference for other front-ends. Oh and for -fno-tree-ter, duplicating the comparison is just a

[pushed] c++: #pragma target and deferred instantiation [PR115403]

Tested x86_64-pc-linux-gnu, applying to trunk. Also built highway to check. -- 8< -- My patch for 109753 applies the current #pragma target/optimize to a function when we compile it, which was a problem for a template instantiation deferred until EOF, where different #pragmas are active. So

Re: [PATCH] rs6000, Add new overloaded vector shift builtin int128, varients

Peter, Segher: On 7/23/24 2:26 PM, Peter Bergner wrote: On 7/19/24 3:04 PM, Carl Love wrote: diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md index 5af9bf920a2..2a18ee44526 100644 --- a/gcc/config/rs6000/altivec.md +++ b/gcc/config/rs6000/altivec.md @@ -878,9 +878,9 @@

Re: [PATCH] rs6000, Add new overloaded vector shift builtin int128, varients

Kewen: On 7/25/24 1:21 AM, Kewen.Lin wrote: Hi Carl, Some minor comments are inlined on top of Segher's and Peter's comments. on 2024/7/20 04:04, Carl Love wrote: GCC developers: The following patch adds the int128 varients to the existing overloaded built-ins vec_sld, vec_sldb, vec_sldw,

Question on SUBREG simplification for big endian target.

We don't really have a good place for discussions anymore other than gcc-patches, but this really isn't a patch.. Oh well. I'm debugging a failure of ext-dce on a big endian target (m68k) and I can't help but think it's actually exposed a latent bug in subreg handling. Your input would be

[PATCH] gimple-ssa-sprintf: Fix typo in range check

The code to scale ranges for wide chars in format_string incorrectly checks range.likely to scale range.unlikely, which is a copy-paste typo from the immediate previous condition. gcc/ChangeLog: gimple-ssa-sprintf.cc (format_string): Fix type in range check for UNLIKELY for wide

Re: [PATCH v1 1/2] PR116080: Fix tail call dejagnu checks

On Thu, Jul 25, 2024 at 4:09 PM Sam James wrote: > > Andi Kleen writes: > > > From: Andi Kleen > > > > - Run the target_effective tail_call checks without optimization to > > match the actual test cases. > > - Add an extra check for external tail calls to handle targets like > > powerpc that

Re: [PATCH v1 1/2] PR116080: Fix tail call dejagnu checks

Andi Kleen writes: > From: Andi Kleen > > - Run the target_effective tail_call checks without optimization to > match the actual test cases. > - Add an extra check for external tail calls to handle targets like > powerpc that cannot tail call between different object files. > This one will also

[PATCH v1 2/2] PR116019: Improve tail call error message

From: Andi Kleen The "tail call must be the same type" message is common on some targets with C++, or without optimization. It is generated when gcc believes there is an access of the return value after the call. However usually it does not actually corespond to a type mismatch, but can be

[PATCH v1 1/2] PR116080: Fix tail call dejagnu checks

From: Andi Kleen - Run the target_effective tail_call checks without optimization to match the actual test cases. - Add an extra check for external tail calls to handle targets like powerpc that cannot tail call between different object files. This one will also cover templates.

[committed] libstdc++: Remove std::basic_format_args default constructor (LWG 4106)

Tested x86_64-linux. Pushed to trunk. -- >8 -- There's no valid use case for default constructing this type, so the committee approved removing the default constructor. libstdc++-v3/ChangeLog: * include/std/format (basic_format_args): Remove default constructor, as per LWG

[committed] libstdc++: Add static_assert to std::expected for LWG 3843 and 3940

Tested x86_64-linux. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * include/std/expected (expected::value): Add assertions for LWG 3843 requirements. (expected::value): Add assertions for LWG 3940 requirements. --- libstdc++-v3/include/std/expected | 8

[committed] libstdc++: Implement P2968R2 "Making std::ignore a first-class object"

Tested x86_64-linux. Pushed to trunk. -- >8 -- This was recently approved for C++26, but we can apply the changes for all modes back to C++11. There's no reason not to make the assignment usable in constant expressions for C++11 mode, and noexcept for all modes. Move the definitions to so

[committed] libstdc++: Reorder template params of std::optional comparisons (LWG 2945)

Tested x86_64-linux. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * include/std/optional: Reorder parameters in comparison operators as per LWG 2945. --- libstdc++-v3/include/std/optional | 36 +++ 1 file changed, 18 insertions(+), 18

Re: [PATCH 4/5] MATCH: Create BIT_ANDN and BIT_IORN from matching

On Thu, Jul 25, 2024 at 5:16 AM Richard Biener wrote: > > On Thu, Jul 25, 2024 at 4:16 AM Andrew Pinski > wrote: > > > > To better create rtl directly from gimple, we can use > > these already internal functions from the gimple. > > > > That is simplify `a & ~b` into BIT_ANDN. > > Likewise `a |

Re: [PATCH 2/2] rs6000, remove built-ins __builtin_vsx_set_1ti, __builtin_vsx_set_2df, __builtin_vsx_set_2di

Kewen: On 7/25/24 1:24 AM, Kewen.Lin wrote: optimization the number of assembly generated for the two methods are similar.  With -O3 optimization, the assembly generated for the two approaches is identical for the 2DF and 2DI types.  The assembly for the C-code version of the 1Ti requres one

Re: [PATCH 0/2] rs6000, remove vec and vsx set builtins

Kewen: On 7/25/24 1:21 AM, Kewen.Lin wrote: The patch, first patch in this series, to remove the __builtin_vec_set_v1ti, __builtin_vec_set_v2df, __builtin_vec_set_v2di was previously posted.  The feedback on the patch was that we could also remove set bif attribute.  Removal of the set bif

Re: [PATCH] MATCH: Optimize `VEC_SHL_INSERT (dup (A), A)` to just `dup (A) [PR116075]

On Thu, Jul 25, 2024 at 10:20 AM Richard Biener wrote: > > > > > Am 25.07.2024 um 17:56 schrieb Andrew Pinski : > > > > It was noticed if we have `.VEC_SHL_INSERT ({ 0, ... }, 0)` it was not > > being > > simplified to just `{ 0, ... }`. This was generated from the autovectorizer > > (maybe

Re: [PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

On 7/25/24 2:17 PM, Patrick Palka wrote: On Mon, 22 Jul 2024, Jason Merrill wrote: On 7/19/24 10:30 AM, Patrick Palka wrote: On Thu, 18 Jul 2024, Jason Merrill wrote: On 7/18/24 12:45 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does thi look OK for trunk/14?

[PATCH] aarch64: Fix target/optimize option handling with transiting between O1 to O2

The problem here is the aarch64 backend enables -mearly-ra at -O2 and above but it is not marked as an Optimization in the .opt file so enabling it sometimes reset the target options when going from -O1 to -O2 for the first time. Build and tested for aarch64-linux-gnu with no regressions.

Re: [PATCH 1/2] rs6000, Remove __builtin_vec_set_v1ti,, __builtin_vec_set_v2df, __builtin_vec_set_v2di

Kewen: On 7/25/24 1:22 AM, Kewen.Lin wrote: on 2024/7/24 01:52, Carl Love wrote: GCC maintainers: This patch was previously posted.  Per the feedback, it is now the first of two patches to remove the set built-ins. This patch removes the __builtin_vec_set_v1ti, __builtin_vec_set_v2df and

Re: [PATCH 1/2] rs6000, Remove __builtin_vec_set_v1ti,, __builtin_vec_set_v2df, __builtin_vec_set_v2di

Kewen: On 7/25/24 1:22 AM, Kewen.Lin wrote: - rs6000, Remove __builtin_vec_set_v1ti, __builtin_vec_set_v2df, __builtin_vec_set_v2di Remove the built-ins, use the default gimple

Re: [PATCH v2] MATCH: Simplify (a ? x : y) eq/ne (b ? x : y) [PR111150]

On Thu, Jul 25, 2024 at 12:01 PM Adhemerval Zanella Netto wrote: > > > > On 17/07/24 14:00, Andrew Pinski wrote: > > On Wed, Jul 17, 2024 at 5:24 AM Richard Biener > > wrote: > >> > >> On Tue, Jul 16, 2024 at 3:36 PM Eikansh Gupta > >> wrote: > >>> > >>> This patch adds match pattern for `(a ?

Re: [PATCH v3 01/12] OpenMP: metadirective tree data structures and front-end interfaces

On 7/25/24 08:00, Tobias Burnus wrote: Hi Sandra, thanks for your patch. (Disclaimer: I have not finished reading through your patch.) Some upfront generic remarks: [* When first compiling it (incremental build), I did run into the issue that OMP_METADIRECTIVE_CHECK wasn't declared. Thus,

Re: [PATCH v2] MATCH: Simplify (a ? x : y) eq/ne (b ? x : y) [PR111150]

On 17/07/24 14:00, Andrew Pinski wrote: > On Wed, Jul 17, 2024 at 5:24 AM Richard Biener > wrote: >> >> On Tue, Jul 16, 2024 at 3:36 PM Eikansh Gupta >> wrote: >>> >>> This patch adds match pattern for `(a ? x : y) eq/ne (b ? x : y)`. >>> In forwprop1 pass, depending on the type of `a` and

Re: [PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

On Thu, 25 Jul 2024, Patrick Palka wrote: > On Mon, 22 Jul 2024, Jason Merrill wrote: > > > On 7/19/24 10:30 AM, Patrick Palka wrote: > > > On Thu, 18 Jul 2024, Jason Merrill wrote: > > > > > > > On 7/18/24 12:45 PM, Patrick Palka wrote: > > > > > Bootstrapped and regtested on

Re: [PATCH] c++: structured bindings and lookup of tuple_size/tuple_element [PR115605]

On 6/25/24 1:00 AM, Andrew Pinski wrote: The problem here is even though we pass std namespace to lookup_template_class as the context, it will look at the current scope for the name too. The fix is to lookup the qualified name first and then use that for lookup_template_class. If

[committed][PR rtl-optimization/116039] Fix life computation for promoted subregs

So this turned out to be a neat little test and while the fuzzer found it on RISC-V, I wouldn't be surprised if the underlying issue is also the root cause of the loongarch issue with ext-dce. The key issue is that if we have something like (set (dest) (any_extend (subreg (source If the

Re: [PATCH] c++: Implement C++26 P2558R2 - Add @, $, and ` to the basic character set [PR110343]

On 7/17/24 6:04 PM, Jakub Jelinek wrote: Hi! The following patch implements the easy parts of the paper. When @$` are added to the basic character set, it means that R"@$`()@$`" should now be valid (here I've noticed most of the raw string tests were tested solely with -std=c++11 or

Re: [PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

On Mon, 22 Jul 2024, Jason Merrill wrote: > On 7/19/24 10:30 AM, Patrick Palka wrote: > > On Thu, 18 Jul 2024, Jason Merrill wrote: > > > > > On 7/18/24 12:45 PM, Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does thi look > > > > OK for trunk/14? > > > > > > >

Re: [PATCH] MATCH: Optimize `VEC_SHL_INSERT (dup (A), A)` to just `dup (A) [PR116075]

> Am 25.07.2024 um 17:56 schrieb Andrew Pinski : > > It was noticed if we have `.VEC_SHL_INSERT ({ 0, ... }, 0)` it was not being > simplified to just `{ 0, ... }`. This was generated from the autovectorizer > (maybe even on accident, see PR tree-optmization/116081). > > This adds a few SVE

[PATCH] MATCH: Optimize `VEC_SHL_INSERT (dup (A), A)` to just `dup (A) [PR116075]

It was noticed if we have `.VEC_SHL_INSERT ({ 0, ... }, 0)` it was not being simplified to just `{ 0, ... }`. This was generated from the autovectorizer (maybe even on accident, see PR tree-optmization/116081). This adds a few SVE testcases to see if this is optimized since the auto-vectorizer or

Re: [PATCH v2] RISC-V: xtheadmemidx: Fix mode test for pre/post-modify addressing

On Thu, 25 Jul 2024 08:37:05 PDT (-0700), christoph.muell...@vrull.eu wrote: On Thu, Jul 25, 2024 at 5:19 PM Palmer Dabbelt wrote: On Thu, 25 Jul 2024 08:10:25 PDT (-0700), jeffreya...@gmail.com wrote: > > > On 7/25/24 9:06 AM, Christoph Müllner wrote: >> Ok, also to backport to GCC 14? >

Re: [PATCH v2] RISC-V: xtheadmemidx: Fix mode test for pre/post-modify addressing

On Thu, Jul 25, 2024 at 5:19 PM Palmer Dabbelt wrote: > > On Thu, 25 Jul 2024 08:10:25 PDT (-0700), jeffreya...@gmail.com wrote: > > > > > > On 7/25/24 9:06 AM, Christoph Müllner wrote: > >> Ok, also to backport to GCC 14? > > Yes, of course. > > I'm OK with that, but according to the latest

Re: [PATCH v2] RISC-V: xtheadmemidx: Fix mode test for pre/post-modify addressing

On Thu, 25 Jul 2024 08:10:25 PDT (-0700), jeffreya...@gmail.com wrote: On 7/25/24 9:06 AM, Christoph Müllner wrote: Ok, also to backport to GCC 14? Yes, of course. I'm OK with that, but according to the latest status report ,

Re: [PATCH v2] RISC-V: xtheadmemidx: Fix mode test for pre/post-modify addressing

On 7/25/24 9:06 AM, Christoph Müllner wrote: Ok, also to backport to GCC 14? Yes, of course. jeff

Re: [PATCH v2] RISC-V: xtheadmemidx: Fix mode test for pre/post-modify addressing

Ok, also to backport to GCC 14? On Thu, Jul 25, 2024 at 4:56 PM Jeff Law wrote: > > > > On 7/24/24 9:15 AM, Christoph Müllner wrote: > > auto_inc_dec (-O3) performs optimizations like the following > > if RVV and XTheadMemIdx is enabled. > > > > (insn 23 20 27 3 (set (mem:V4QI (reg:DI 136 [

Re: [patch,avr] Implement PR116056: attribute signal(n) and interrupt(n)

On 7/23/24 2:19 PM, Georg-Johann Lay wrote: This patch adds support for arguments to the signal and interrupt function attributes.  It allows to specify the ISR by means of the associated IRQ number, in extension to the current attributes that require to specify the ISR name like "__vector_1"

Re: [PATCH v2] RISC-V: xtheadmemidx: Fix mode test for pre/post-modify addressing

On 7/24/24 9:15 AM, Christoph Müllner wrote: auto_inc_dec (-O3) performs optimizations like the following if RVV and XTheadMemIdx is enabled. (insn 23 20 27 3 (set (mem:V4QI (reg:DI 136 [ ivtmp.13 ]) [0 MEM [(char *)_39]+0 S4 A32]) (reg:V4QI 168))

[committed] Trivial testcase adjustment

I made pr116037.c dependent on int32 just based on the constants used without noting the int128 vector type. Naturally on targets that don't support int128 the test fails. Fixed by changing the target selector from int32 to int128. Pushed to the trunk. Jeff commit

[PATCH v2 2/3] aarch64: Add support for moving fpm system register

Unlike most system registers, fpmr can be heavily written to in code that exercises the fp8 functionality. That is because every fp8 instrinsic call can potentially change the value of fpmr. Rather than just use a an unspec, we treat the fpmr system register like all other registers and use a

[PATCH v2 3/3] aarch64: Add fpm register helper functions.

The ACLE declares several helper types and functions to facilitate construction of `fpm` arguments. gcc/ChangeLog: * config/aarch64/arm_acle.h (fpm_t): New type representing fpmr values. (enum __ARM_FPM_FORMAT): New enum representing valid fp8 formats. (enum

[PATCH v2 1/3] aarch64: Add march flags for +fp8 arch extensions

This introduces the relevant flags to enable access to the fpmr register and fp8 intrinsics, which will be added subsequently. gcc/ChangeLog: * config/aarch64/aarch64-option-extensions.def (fp8): New. * config/aarch64/aarch64.h (TARGET_FP8): Likewise. * doc/invoke.texi

[PATCH v2 0/3] aarch64: Add initial support for +fp8 arch extensions

This series introduces initial flags and functionality for the fp8 feature. Specifically, the following are added: - functions that enable constructing valid fpm register values. - support for the '+fp8' -march modifier. - support for reading and writing the new system register FPMR (Floating

Re: [PATCH 2/2] cp+coroutines: teach convert_to_void to diagnose discarded co_awaits

On 7/24/24 4:52 PM, Arsen Arsenović wrote: Jason Merrill writes: Ah, of course, I was overlooking the assignment. The patch is OK. Thanks. Here's a range diff with a few changes to the commits, chiefly in the commit messages. If you agree, I can push with these changes applied: Looks

Re: [PATCH v3 01/12] OpenMP: metadirective tree data structures and front-end interfaces

Hi Sandra, thanks for your patch. (Disclaimer: I have not finished reading through your patch.) Some upfront generic remarks: [* When first compiling it (incremental build), I did run into the issue that OMP_METADIRECTIVE_CHECK wasn't declared. Thus, there seems to be a dependency issue

[PATCH] fold: Allow SSA names in inverse_conditions_p and fold VCOND_MASK.

Hi, In preparation for the maskload else operand I split off this patch. The patch looks through SSA names for the conditions passed to inverse_conditions_p which helps match.pd recognize more redundant vec_cond expressions. It also adds VCOND_MASK to the respective iterators in match.pd. Is

[PATCH] tree-optimization/116083 - improve behavior when SLP discovery limit is reached

The following avoids some useless work when the SLP discovery limit is reached, for example allocating a node to cache the failure and starting discovery on split store groups when analyzing BBs. It does not address the issue in the PR which is a gratious budget for discovery when the store group

Re: [PATCH v2] RISC-V: Add basic support for the Zacas extension

On Tue, Jul 23, 2024 at 05:15:44PM -0700, Patrick O'Neill wrote: > From: Gianluca Guida > > This patch adds support for amocas.{b|h|w|d}. Support for amocas.q > (64/128 bit cas for rv32/64) will be added in a future patch. > > Extension: https://github.com/riscv/riscv-zacas > Ratification:

Re: [PATCH] aarch64: Fuse CMP+CSEL and CMP+CSET for -mcpu=neoverse-v2

> On 25 Jul 2024, at 13:58, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Jennifer Schmitz writes: >> Thank you for the feedback. I added checks for SCALAR_INT_MODE_P for the reg >> operands of the compare and if-then-else expressions. As it is

Re: PING^3 [PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

Pinging this again. Em seg, 2024-07-22 às 17:18 +0800, Kewen.Lin escreveu: > Hi, > > Gentle ping this patch: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651025.html > > BR, > Kewen > > on 2024/7/12 00:15, Martin Jambor wrote: > > Hi, > > > > can I add myself to the bunch of people

[pushed] rtl-ssa: Define INCLUDE_ARRAY

g:72fbd3b2b2a497dbbe6599239bd61c5624203ed0 added a use of std::array without explicitly forcing to be included. That didn't cause problems in my local builds but understandably did for some people. Bootstrapped on aarch64-linux-gnu & pushed as obvious. Richard gcc/ * doc/rtl.texi:

Re: [PATCH] doc: Document -O1 as the preferred level for large machine-generated code

On Tue, Jul 23, 2024 at 4:07 PM Sam James wrote: > > At -O1, the intention is that we compile things in a "reasonable" amount > of time (ditto memory use). In particular, we try to especially avoid > optimizations which scale poorly on pathological cases, as is the case > for large

Re: [PATCH] MATCH: add abs support for half float

On Thu, Jul 25, 2024 at 4:42 AM Kugan Vivekanandarajah wrote: > > On Tue, Jul 23, 2024 at 11:56 PM Richard Biener > wrote: > > > > On Tue, Jul 23, 2024 at 10:27 AM Kugan Vivekanandarajah > > wrote: > > > > > > On Tue, Jul 23, 2024 at 10:35 AM Andrew Pinski wrote: > > > > > > > > On Mon, Jul

Re: [PATCH 5/5] MATCH: Add an alt pattern for ANDN and IORN with constants

On Thu, Jul 25, 2024 at 4:18 AM Andrew Pinski wrote: > > With constants we can match `~(a | CST)` into `CST & ~a`. > Likewise `~(a & CST)` into `CST | ~a`. > > Built and tested for aarch64-linux-gnu with no regressions. Similar, I think this should be in ISEL instead. > PR target/116013

Re: [PATCH 4/5] MATCH: Create BIT_ANDN and BIT_IORN from matching

On Thu, Jul 25, 2024 at 4:16 AM Andrew Pinski wrote: > > To better create rtl directly from gimple, we can use > these already internal functions from the gimple. > > That is simplify `a & ~b` into BIT_ANDN. > Likewise `a | ~b` into BIT_IORN. > We only want to do this late after vectorization as

Re: [PATCH] aarch64: Fuse CMP+CSEL and CMP+CSET for -mcpu=neoverse-v2

Jennifer Schmitz writes: > Thank you for the feedback. I added checks for SCALAR_INT_MODE_P for the reg > operands of the compare and if-then-else expressions. As it is not legal to > have different modes in the operand registers, I only added one check for > each of the expressions. > The

[PATCH] tree-optimization/116081 - typedef vs. non-typedef in vectorization

The following fixes the code generation difference when using a typedef for the scalar type. The issue is using a pointer equality test for an INTEGER_CST which fails when the types are different variants. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR

Re: [PATCH] c++/modules: Implement P2615 'Meaningful Exports' [PR107688]

On Tue, Apr 30, 2024 at 02:46:15PM -0400, Jason Merrill wrote: > On 3/4/24 06:18, Nathaniel Shead wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu. This should probably > > wait for GCC 15 I suppose, but sending it in now in case there are any > > comments. > > OK for trunk. I've

Re: [PATCH] doc: Document -O1 as the preferred level for large machine-generated code

Eric Gallager writes: > On Tue, Jul 23, 2024 at 10:07 AM Sam James wrote: >> >> At -O1, the intention is that we compile things in a "reasonable" amount >> of time (ditto memory use). In particular, we try to especially avoid >> optimizations which scale poorly on pathological cases, as is the

[committed] libstdc++: Use concepts and conditional explicit in std::optional

Tested x86_64-linux. Pushed to trunk. -- >8 -- For C++20 mode we can improve compile times by using conditional explicit to reduce the number of constructor overloads. We can also use requires-clauses instead of SFINAE to implement constraints on the constructors and assignment operators.

Re: [PATCH] libstdc++: fix uses of explicit object parameter [PR116038]

On Thu, 25 Jul 2024 at 01:04, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 (after > 14.2 is released)? Yes to both, thanks. > > -- >8 -- > > The type of an implicit object parameter is always the current class. > For an explicit object parameter

[PATCH] tree-optimization/116079 - store motion and clobbers

When we move a store out of an inner loop and remove a clobber in the process, analysis of the inner loop can run into the clobber via the meta-data and crash when accessing its basic-block. The following avoids this by clearing the VDEF which is how it identifies already processed stores.

[PATCH] tree-optimization/116081 - typedef vs. non-typedef in vectorization

The following addresses a behavioral difference in vector type analysis for typedef vs. non-typedef. It doesn't fix the issue at hand but avoids a spurious difference in the dumps. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/116081 *

Re: [PATCH] libstdc++: Fix testsuite for remote testing (and sim)

On Thu, 25 Jul 2024 at 07:32, Jonathan Wakely wrote: > > > > On Thu, 25 Jul 2024, 02:58 Andrew Pinski, wrote: >> >> The problem here is that v3_additional_files will have a space >> at the begining of the string as dg-additional-files will append >> `" " $files` to it. Then when split is called

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Can you post an updated version of the patch, following the first round of review? FX

Re: [PATCH] doc: Document -O1 as the preferred level for large machine-generated code

On Tue, Jul 23, 2024 at 10:07 AM Sam James wrote: > > At -O1, the intention is that we compile things in a "reasonable" amount > of time (ditto memory use). In particular, we try to especially avoid > optimizations which scale poorly on pathological cases, as is the case > for large

Re: [PATCH ver 2] rs6000, remove __builtin_vsx_xvcmp* built-ins

Hi Carl, on 2024/7/24 01:06, Carl Love wrote: > GCC maintainers: > > version 2, Updated patch comments, added missing ChangeLog.  Fixed unintended > line removal. > > The following patch removes the three __builtin_vsx_xvcmp[eq|ge|gt]sp  > builtins as they similar to the overloaded

Re: [PATCH 1/2] rs6000, Remove __builtin_vec_set_v1ti,, __builtin_vec_set_v2df, __builtin_vec_set_v2di

Hi Carl, on 2024/7/24 01:52, Carl Love wrote: > > GCC maintainers: > > This patch was previously posted.  Per the feedback, it is now the first of > two patches to remove the set built-ins. > > This patch removes the __builtin_vec_set_v1ti, __builtin_vec_set_v2df and > __builtin_vec_set_v2di

Re: [PATCH 2/2] rs6000, remove built-ins __builtin_vsx_set_1ti, __builtin_vsx_set_2df, __builtin_vsx_set_2di

Hi Carl, on 2024/7/24 01:52, Carl Love wrote: > GCC maintainers: > > This patch removes the vsx set built-ins: __builtin_vsx_set_1ti, > __builtin_vsx_set_2df, __builtin_vsx_set_2di.  With the  removal of these > built-ins, the built-in attribute "set", used in the built-in definition > file,

Re: [PATCH 0/2] rs6000, remove vec and vsx set builtins

Hi Carl, on 2024/7/24 01:32, Carl Love wrote: > GCC maintainers: > > The code generated by using C-code to set a vector element versus using a > built-in has been investigated.  The assembly code generated from the C-code > is as good or better than the assembly code generated for the

Re: [PATCH] rs6000, Add new overloaded vector shift builtin int128, varients

Hi Carl, Some minor comments are inlined on top of Segher's and Peter's comments. on 2024/7/20 04:04, Carl Love wrote: > GCC developers: > > The following patch adds the int128 varients to the existing overloaded > built-ins vec_sld, vec_sldb, vec_sldw, vec_sll, vec_slo, vec_srdb, vec_srl, >

Re: [PATCH] [x86]Refine constraint "Bk" to define_special_memory_constraint.

On Wed, Jul 24, 2024 at 3:57 PM liuhongt wrote: > > For below pattern, RA may still allocate r162 as v/k register, try to > reload for address with leaq __libc_tsd_CTYPE_B@gottpoff(%rip), %rsi > which result a linker error. > > (set (reg:DI 162) > (mem/u/c:DI >(const:DI (unspec:DI >

Re: [PATCH 2/5] aarch64: sve: Rename aarch64_bic to standard pattern, andn

> On 25 Jul 2024, at 04:14, Andrew Pinski wrote: > > External email: Use caution opening links or attachments > > > Now there is an optab for bic, andn since r15-1890-gf379596e0ba99d. > This moves aarch64_bic for sve over to use it instead. > > Note unlike the simd bic patterns, the

Re: [PATCH] SVE Intrinsics: Change return type of redirect_call to gcall.

> On 24 Jul 2024, at 18:50, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Jennifer Schmitz writes: >> As suggested in the review of >> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657474.html, >> this patch changes the return type of

Re: [PATCH] libstdc++: Fix testsuite for remote testing (and sim)

On Thu, 25 Jul 2024, 02:58 Andrew Pinski, wrote: > The problem here is that v3_additional_files will have a space > at the begining of the string as dg-additional-files will append > `" " $files` to it. Then when split is called on that string, > there will be an empty file and copying a dir

Re: [PATCH 1/5] aarch64: Rename bic/orn patterns to iorn/andn for vector modes

On Wed, Jul 24, 2024 at 11:22 PM Kyrylo Tkachov wrote: > > > > > On 25 Jul 2024, at 04:14, Andrew Pinski wrote: > > > > External email: Use caution opening links or attachments > > > > > > This renames the patterns orn3 to iorn3 so it > > matches the new optab that was added with

Re: [PATCH 3/5] aarch64: Use iorn and andn standard pattern names for scalar modes

Hi Andrew, > On 25 Jul 2024, at 04:14, Andrew Pinski wrote: > > External email: Use caution opening links or attachments > > > Since r15-1890-gf379596e0ba99d, these are the new optabs. > So let's use these names for them. These will be used to > generate during expand from gimple in the next

Re: [PATCH 1/5] aarch64: Rename bic/orn patterns to iorn/andn for vector modes

> On 25 Jul 2024, at 04:14, Andrew Pinski wrote: > > External email: Use caution opening links or attachments > > > This renames the patterns orn3 to iorn3 so it > matches the new optab that was added with r15-1890-gf379596e0ba99d. > Likewise for bic3 to andn3. > > Note the operand 1 and

[PATCHv3, rs6000] Optimize vector construction with two vector doubleword loads [PR103568]

Hi, This patch optimizes vector construction with two vector doubleword loads. It generates an optimal insn sequence as "xxlor" has lower latency than "mtvsrdd" on Power10. Compared with previous version, the main change is to add new patterns for LE platform. Also lxsd[x] instructions are