[PATCH] i386: Adjust rtx cost for imulq and imulw [PR115749]

Tested spec2017 performance in Sierra Forest, Icelake, CascadeLake, at least there is no obvious regression. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. OK for trunk? gcc/ChangeLog: * config/i386/x86-tune-costs.h (struct processor_costs): Adjust rtx_cost of imulq

Re: [PATCH] regrename: Skip renaming register pairs [PR115860]

On Tue, Jul 23, 2024 at 11:40:00AM -0600, Jeff Law wrote: > > > On 7/23/24 9:45 AM, Stefan Schulze Frielinghaus wrote: > > > > > > They come from: > > > ``` > > > (define_insn "*tf_to_fprx2_0" > > >[(set (subreg:DF (match_operand:FPRX2 0 "nonimmediate_operand" "+f") 0) > > > (subre

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

On 22/07/2024 11:07, Alex Coplan wrote: > Hi Claudio, > > I've left a couple of small comments below. > > On 22/07/2024 09:30, Claudio Bantaloukas wrote: --8<- >> >> @@ -1505,6 +1513,8 @@ (define_insn_and_split "*movdi_aarch64" >>[w, w ; fmov , fp , 4] fmov\t%d0, %d1 >>

[PATCH] RISC-V: Disable Zba optimization pattern if XTheadMemIdx is enabled

It is possible that the Zba optimization pattern zero_extendsidi2_bitmanip matches for a XTheadMemIdx INSN with the effect of emitting an invalid instruction as reported in PR116035. The pattern above is used to emit a zext.w instruction to zero-extend SI mode registers to DI mode. A similar func

Re: [PATCH] RISC-V: Disable Zba optimization pattern if XTheadMemIdx is enabled

LGTM :) On Wed, Jul 24, 2024 at 3:16 PM Christoph Müllner wrote: > > It is possible that the Zba optimization pattern zero_extendsidi2_bitmanip > matches for a XTheadMemIdx INSN with the effect of emitting an invalid > instruction as reported in PR116035. > > The pattern above is used to emit a z

Re: [PATCH] optabs/rs6000: Rename iorc and andc to iorn and andn

Hi Andrew, on 2024/7/24 10:49, Andrew Pinski wrote: > When I was trying to add an scalar version of iorc and andc, the optab that > got matched was for and/ior with the mode of csi and cdi instead of iorc and > andc optabs for si and di modes. Since csi/cdi are the complex integer modes, > we need

Re: [RFC/PATCH] isel: Fold more in gimple_expand_vec_cond_expr with andc/iorc

on 2024/7/24 06:53, Andrew Pinski wrote: > On Mon, Jul 22, 2024 at 7:41 PM Kewen.Lin wrote: >> >> Hi Andrew, >> >> on 2024/7/23 08:09, Andrew Pinski wrote: >>> On Sun, Jun 30, 2024 at 11:17 PM Kewen.Lin wrote: Hi, As PR115659 shows, assuming c = x CMP y, there are some fo

Re: [PATCH][contrib]: support json output from check_GNU_style_lib.py

> How about this formatting, I tend to find it a bit easier to read even. > I also updated the location numbering to be numerical so, removed the quotes. > > Ok for master? > > Thanks, > Tamar > > +elif format == 'json': > +fn = lambda x: x.error_message > +i = 1 > +r

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

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 [(symbol_ref:DI ("a") [flags 0x60] )]

Re: [PATCH] RISC-V: Disable Zba optimization pattern if XTheadMemIdx is enabled

Is it OK to backport to GCC 14 (patch applies cleanly, test is running)? On Wed, Jul 24, 2024 at 9:25 AM Kito Cheng wrote: > > LGTM :) > > On Wed, Jul 24, 2024 at 3:16 PM Christoph Müllner > wrote: > > > > It is possible that the Zba optimization pattern zero_extendsidi2_bitmanip > > matches for

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

The following typo was corrected, updated patch file below: /* Fuse CMP and CSET. */ - if (aarch64_fusion_enabled_p (AARCH64_FUSE_CMP_CSEL) + if (aarch64_fusion_enabled_p (AARCH64_FUSE_CMP_CSET) 0001-aarch64-Fuse-CMP-CSEL-and-CMP-CSET-for-mcpu-neoverse.patch Description: Binary data > On 23 Ju

Patch ping

Hi! I'd like to ping the C23 #embed patchset: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655012.html https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655013.html

RE: [PATCH v2] AArch64: Add LUTI ACLE for SVE2

Hi Kyrill, Thanks for your prompt review again! >It looks like __ARM_FEATURE_LUT should guard the Advanced SIMD intrinsics for >LUTI at least. >Therefore we should add this macro definition only once those are implemented >as well. So I’d remove this hunk. I'm working on adding those Advanced S

[Patch, rs6000] lmprove loop_unroll_adjust

Hello All: This patch improves loop_unroll_adjust by adding mem count to calculate unroll factor. Bootstrapped and regtested on powerpc64-linux-gnu. Thanks & Regards Ajit rs6000: Improve loop_unroll_adjust Improves loop_unroll_adjust by adding mem count to calculate unroll factor. 2024-07-24

Re: [PATCH v2] AArch64: Add LUTI ACLE for SVE2

Hi Vladimir, > On 24 Jul 2024, at 11:41, Vladimir Miloserdov > wrote: > > External email: Use caution opening links or attachments > > > Hi Kyrill, > > Thanks for your prompt review again! > >> It looks like __ARM_FEATURE_LUT should guard the Advanced SIMD intrinsics >> for LUTI at least.

Re: [PATCH v3 2/2] Prevent divide-by-zero

> Thanks for the explanation! I have a few clarification questions about this. > If I understand correctly, B would represent the number of elements the > vector can have (for 128b vector operating on 32b elements, B == 4, but if > operating on 64b elements B == 2); however, I'm not too sure what A

[PATCH] gm2: fix bad programming practice warning

Fix identifier names to be too similar to Modula-2 keywords and causing warnings coming from Modula-2's own libraries. m2/m2iso/StdChans.mod:54:20: note: In implementation module ‘StdChans’: either the identifier has the same name as a keyword or alternatively a keyword has the wrong case (‘IN’ an

RE: [PATCH][contrib]: support json output from check_GNU_style_lib.py

Hi Tamar, A few suggestions below. >diff --git a/contrib/check_GNU_style_lib.py b/contrib/check_GNU_style_lib.py >index >>6dbe4b53559c63d2e0276d0ff88619cd2f7f8e06..ab21ed4607593668ab95f24715295a41ac7d8>a21 > 100755 >--- a/contrib/check_GNU_style_lib.py >+++ b/contrib/check_GNU_style_lib.py >@@

Re: [PATCH] optabs/rs6000: Rename iorc and andc to iorn and andn

On Wed, Jul 24, 2024 at 9:38 AM Kewen.Lin wrote: > > Hi Andrew, > > on 2024/7/24 10:49, Andrew Pinski wrote: > > When I was trying to add an scalar version of iorc and andc, the optab that > > got matched was for and/ior with the mode of csi and cdi instead of iorc and > > andc optabs for si and d

Re: [PATCH v3 2/2] Prevent divide-by-zero

On Wed, Jul 24, 2024 at 1:31 AM Edwin Lu wrote: > > > On 7/23/2024 11:20 AM, Richard Sandiford wrote: > > Edwin Lu writes: > >> On 7/23/2024 4:56 AM, Richard Biener wrote: > >>> On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu wrote: > Hi Richard, > > On 5/31/2024 1:48 AM, Richard Biener

Re: [PATCH v2] MATCH: Add simplification for MAX and MIN to match.pd [PR109878]

On Fri, Jul 19, 2024 at 7:19 PM Eikansh Gupta wrote: > > Min and max could be optimized if both operands are defined by > (same) variable restricted by an and(&). For signed types, > optimization can be done when both constant have same sign bit. > The patch also adds optimization for specific cas

Re: [PATCH 1/8] libstdc++: Clean up @diff@ markup in some I/O tests

I've pushed this series to trunk now. On Mon, 22 Jul 2024 at 17:34, Jonathan Wakely wrote: > > Tested x86_64-linux. > > -- >8 -- > > We have a number of 27_io/* tests with comments like this: > > // @require@ %-*.tst > // @diff@ %-*.tst %-*.txt > > It seems that these declare required data files

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

Hi Jennifer, > On 24 Jul 2024, at 10:52, Jennifer Schmitz wrote: > > The following typo was corrected, updated patch file below: > > /* Fuse CMP and CSET. */ > - if (aarch64_fusion_enabled_p (AARCH64_FUSE_CMP_CSEL) > + if (aarch64_fusion_enabled_p (AARCH64_FUSE_CMP_CSET) > <0001-aarch64-Fuse-CM

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

Kyrylo Tkachov writes: > Hi Jennifer, > >> On 24 Jul 2024, at 10:52, Jennifer Schmitz wrote: >> >> The following typo was corrected, updated patch file below: >> >> /* Fuse CMP and CSET. */ >> - if (aarch64_fusion_enabled_p (AARCH64_FUSE_CMP_CSEL) >> + if (aarch64_fusion_enabled_p (AARCH64_FUSE

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

> On 24 Jul 2024, at 13:34, Kyrylo Tkachov wrote: > > Hi Jennifer, > >> On 24 Jul 2024, at 10:52, Jennifer Schmitz wrote: >> >> The following typo was corrected, updated patch file below: >> >> /* Fuse CMP and CSET. */ >> - if (aarch64_fusion_enabled_p (AARCH64_FUSE_CMP_CSEL) >> + if (aarch

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

> On 24 Jul 2024, at 13:38, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Kyrylo Tkachov writes: >> Hi Jennifer, >> >>> On 24 Jul 2024, at 10:52, Jennifer Schmitz wrote: >>> >>> The following typo was corrected, updated patch file below: >>>

[PATCH] rtl-ssa: Fix split_clobber_group tree insertion [PR116044]

PR116044 is a regression in the testsuite on AMD GCN caused (again) by the split_clobber_group code. The first patch in this area (g:71b31690a7c52413496e91bcc5ee4c68af2f366f) fixed a bug caused by carrying the old group over as one the split ones. That patch instead: - created two new groups - i

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

On 24 Jul 2024, at 13:40, Kyrylo Tkachov wrote: On 24 Jul 2024, at 13:34, Kyrylo Tkachov wrote: Hi Jennifer, On 24 Jul 2024, at 10:52, Jennifer Schmitz wrote: The following typo was corrected, updated patch file below: /* Fuse CMP and CSET. */ - if (aarch64_fusion_enabled_p (AARCH64_FUS

[PATCH] tree-optimization/116057 - wrong code with CCP and vector CTORs

The following fixes an issue with CCPs likely_value when faced with a vector CTOR containing undef SSA names and constants. This should be classified as CONSTANT and not UNDEFINED. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/116057 * tree-ssa

[PATCH] RISC-V: Error early with V and no M extension. [PR116036]

Hi, for calculating the value of a poly_int at runtime we use a multiplication instruction that requires the M extension. Instead of just asserting and ICEing this patch emits an early error at option-parsing time. We have several tests that use only "i" (without "m") and I adjusted all of them

[PATCH] libstdc++: Fix future.wait_until when given a negative time_point

The template `future.wait_until` will expand to `_M_load_and_test_until_impl` where it will call `_M_load_and_test_until*` with given time_point casted into second and nanosecond. The callee expects the caller to provide the values correctly from caller while the caller did not make check with thos

[PATCH] RISC-V: xtheadmemidx: Disable pre/post-modify addressing if RVV is enabled

When enabling XTheadMemIdx, we enable the pre- and post-modify addressing modes in the RISC-V backend. Unfortunately, the auto_inc_dec pass will then attempt to utilize this feature regardless of the mode class (i.e. scalar or vector). The assumption seems to be, that an enabled addressing mode for

[PATCH] Maintain complex constraint vector order during PTA solving

There's a FIXME comment in the PTA constraint solver that the vector of complex constraints can get unsorted which can lead to duplicate entries piling up during node unification. The following fixes this with the assumption that delayed updates to constraints are uncommon (otherwise re-sorting th

Re: [PATCH] RISC-V: Error early with V and no M extension. [PR116036]

LGTM, although I was a little late to join the meeting yesterday, but I vaguely know you guys are discussing this, that combination really does not make too much sense and also the LLVM side already does the same thing :) On Wed, Jul 24, 2024 at 8:50 PM Robin Dapp wrote: > > Hi, > > for calculati

Re: [PATCH] RISC-V: Disable Zba optimization pattern if XTheadMemIdx is enabled

Yeah, OK once your local test passes :) On Wed, Jul 24, 2024 at 4:38 PM Christoph Müllner wrote: > > Is it OK to backport to GCC 14 (patch applies cleanly, test is running)? > > On Wed, Jul 24, 2024 at 9:25 AM Kito Cheng wrote: > > > > LGTM :) > > > > On Wed, Jul 24, 2024 at 3:16 PM Christoph Mü

Re: [PATCH] RISC-V: xtheadmemidx: Disable pre/post-modify addressing if RVV is enabled

LGTM :) On Wed, Jul 24, 2024 at 9:31 PM Christoph Müllner wrote: > > When enabling XTheadMemIdx, we enable the pre- and post-modify > addressing modes in the RISC-V backend. > Unfortunately, the auto_inc_dec pass will then attempt to utilize > this feature regardless of the mode class (i.e. scala

Re: [PATCH] RISC-V: xtheadmemidx: Disable pre/post-modify addressing if RVV is enabled

On 7/24/24 7:31 AM, Christoph Müllner wrote: When enabling XTheadMemIdx, we enable the pre- and post-modify addressing modes in the RISC-V backend. Unfortunately, the auto_inc_dec pass will then attempt to utilize this feature regardless of the mode class (i.e. scalar or vector). The assumptio

Re: [PATCH] RISC-V: Error early with V and no M extension. [PR116036]

On 7/24/24 7:54 AM, Kito Cheng wrote: LGTM, although I was a little late to join the meeting yesterday, but I vaguely know you guys are discussing this, that combination really does not make too much sense and also the LLVM side already does the same thing :) Yea, the idea was this combination

Re: [PATCH] RISC-V: Error early with V and no M extension. [PR116036]

> diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc > index 826d552a6fd..eb6c033535c 100644 > --- a/gcc/internal-fn.cc > +++ b/gcc/internal-fn.cc > @@ -5049,7 +5049,8 @@ internal_len_load_store_bias (internal_fn ifn, > machine_mode mode) > } > > /* Return true if the given ELS_VALUE is supp

Re: [PATCH] RISC-V: xtheadmemidx: Disable pre/post-modify addressing if RVV is enabled

On Wed, Jul 24, 2024 at 3:57 PM Jeff Law wrote: > > > > On 7/24/24 7:31 AM, Christoph Müllner wrote: > > When enabling XTheadMemIdx, we enable the pre- and post-modify > > addressing modes in the RISC-V backend. > > Unfortunately, the auto_inc_dec pass will then attempt to utilize > > this feature

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

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 updated patch was bootstrapped and teste

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

As suggested in the review of https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657474.html, this patch changes the return type of gimple_folder::redirect_call from gimple * to gcall *. The motivation for this is that so far, most callers of the function had been casting the result of the functio

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

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)) "gcc/testsuite/gcc.target/riscv/pr116033.c":12:27 3183 {*movv4qi} (nil)) (insn 4

[PATCH v2] RISC-V: Error early with V and no M extension.

Hi, now with proper diff... For calculating the value of a poly_int at runtime we use a multiplication instruction that requires the M extension. Instead of just asserting and ICEing this patch emits an early error at option-parsing time. We have several tests that use only "i" (without "m") and

Re: [PATCH v2] RISC-V: Error early with V and no M extension.

On Wed, 24 Jul 2024 08:25:30 PDT (-0700), Robin Dapp wrote: Hi, now with proper diff... For calculating the value of a poly_int at runtime we use a multiplication instruction that requires the M extension. Instead of just asserting and ICEing this patch emits an early error at option-parsing ti

Re: [PATCH v2] RISC-V: Error early with V and no M extension.

> It's really GCC's implementation of the V extension that requires M, not > the actul ISA V extension. So I think the wording could be a little > confusing for users here, but no big deal either way on my end so > > Reviewed-by: Palmer Dabbelt Hmm, fair. How about just "the 'V' implementatio

Re: [PATCH v2] RISC-V: Error early with V and no M extension.

On 7/24/24 08:37, Robin Dapp wrote: It's really GCC's implementation of the V extension that requires M, not the actul ISA V extension. So I think the wording could be a little confusing for users here, but no big deal either way on my end so Reviewed-by: Palmer Dabbelt Hmm, fair. How abou

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

Peter: 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 @@ (define_i

Re: [PATCH v2] RISC-V: Error early with V and no M extension.

> That phrasing makes sense to me. It's consistent with the -mbig-endian > sorry message: > > https://godbolt.org/z/oWMeorEeM I seem to remember that explicitly mentioning GCC in an error message like that was discouraged but I might be confusing things. So probably "GCC's current 'V' implementa

[PATCH] libcpp, c++, v2: Optimize initializers using #embed in C++

On Tue, Jul 23, 2024 at 09:38:15PM -0400, Jason Merrill wrote: Thanks. > > but please see > > https://github.com/llvm/llvm-project/pull/97274#issuecomment-2230929277 > > comment and whether we really want the preprocessor to preprocess it for > > C++ as (or as-if) > > static_cast(127),static_cast

[committed 01/11] aarch64: Remove unused global aarch64_tune_flags

gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_tune_flags): Remove unused global variable. (aarch64_override_options_internal): Remove dead assignment. diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc index 9e51236ce9fa059ccc6e4fe24335b5fb3

[committed 00/11] aarch64: Extend aarch64_feature_flags to 128 bits

The end goal of the series is to change the definition of aarch64_feature_flags from a uint64_t typedef to a class with 128 bits of storage. This class is a new template bitmap type that uses operator overloading to mimic the existing integer interface as much as possible. The changes are mostly

[committed 02/11] aarch64: Move AARCH64_NUM_ISA_MODES definition

AARCH64_NUM_ISA_MODES will be used within aarch64-opts.h in a later commit. gcc/ChangeLog: * config/aarch64/aarch64.h (DEF_AARCH64_ISA_MODE): Move to... * config/aarch64/aarch64-opts.h (DEF_AARCH64_ISA_MODE): ...here. diff --git a/gcc/config/aarch64/aarch64-opts.h b/gcc/config/

[committed 04/11] aarch64: Introduce aarch64_isa_mode type

Currently there are many places where an aarch64_feature_flags variable is used, but only the bottom three isa mode bits are set and read. Using a separate data type for these value makes it more clear that they're not expected or required to have any of their upper feature bits set. It will also

[committed 03/11] aarch64: Eliminate a temporary variable.

The name would become misleading in a later commit anyway, and I think this is marginally more readable. gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_override_options): Remove temporary variable. diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc i

[committed 05/11] aarch64: Define aarch64_get_{asm_|}isa_flags

Building an aarch64_feature_flags value from data within a gcc_options or cl_target_option struct will get more complicated in a later commit. Use a macro to avoid doing this manually in more than one location. gcc/ChangeLog: * common/config/aarch64/aarch64-common.cc (aarch64_hand

[committed 08/11] aarch64: Add bool conversion to TARGET_* macros

Use a new AARCH64_HAVE_ISA macro in TARGET_* definitions, and eliminate all the AARCH64_ISA_* feature macros. gcc/ChangeLog: * config/aarch64/aarch64-c.cc (aarch64_define_unconditional_macros): Use TARGET_V8R macro. (aarch64_update_cpp_builtins): Use TARGET_* macros.

[committed 06/11] aarch64: Decouple feature flag option storage type

The awk scripts that process the .opt files are relatively fragile and only handle a limited set of data types correctly. The unrecognised aarch64_feature_flags type is handled as a uint64_t, which happens to be correct for now. However, that assumption will change when we extend the mask to 128

[committed 09/11] aarch64: Use constructor explicitly in get_flags_off

gcc/ChangeLog: * config/aarch64/aarch64-feature-deps.h (get_flags_off): Construct aarch64_feature_flags (0) explicitly. diff --git a/gcc/config/aarch64/aarch64-feature-deps.h b/gcc/config/aarch64/aarch64-feature-deps.h index 79126db88254b89f74a8583d50a77bc27865e265..a14ae22b729

[committed 10/11] Add new bbitmap class

This class provides a constant-size bitmap that can be used as almost a drop-in replacement for bitmaps stored in integer types. The implementation is entirely within the header file and uses recursive templated operations to support effective optimisation and usage in constexpr expressions. This

[committed 07/11] aarch64: Add explicit bool cast to return value

gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_valid_sysreg_name_p): Add bool cast. diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc index 66ce04d77e17a65d320578de389462756d33d110..7c2af1316b6740ccb7a383b3ac73f7c8ec36889c 100644 --- a/gcc/config/a

[committed 11/11] aarch64: Extend aarch64_feature_flags to 128 bits

Replace the existing uint64_t typedef with a bbitmap<2> typedef. Most of the preparatory work was carried out in previous commits, so this patch itself is fairly small. gcc/ChangeLog: * common/config/aarch64/aarch64-common.cc (aarch64_set_asm_isa_flags): Store a second uint64_t v

[committed 2/2] libstdc++: Fix and for -std=gnu++14 -fconcepts [PR116070]

Tested x86_64-linux. Pushed to trunk. Backports to follow after the 14.2 release. -- >8 -- This questionable combination of flags causes a number of errors. The ones in the rvalue stream overloads need to be fixed in the gcc-14 branch so I'm committing it separately to simplify backporting. lib

[committed 1/2] libstdc++: Fix std::vector for -std=gnu++14 -fconcepts [PR116070]

Tested x86_64-linux. Pushed to trunk. Backports to follow after the 14.2 release. -- >8 -- This questionable combination of flags causes a number of errors. This one in std::vector needs to be fixed in the gcc-13 branch so I'm committing it separately to simplify backporting. libstdc++-v3/Chang

[committed] testsuite: Fix up pr116034.c test for big/pdp endian [PR116061]

Hi! Didn't notice the memmove is into an int variable, so the test was still failing on big endian. Committed to trunk as obvious. 2024-07-24 Jakub Jelinek PR tree-optimization/116034 PR testsuite/116061 * gcc.dg/pr116034.c (g): Change type from int to unsigned short.

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

On 7/23/24 19:48, Kito Cheng wrote: I incline do not add skip_zacas stuffs (although skip_zabha is already there but that's fine), because that's different situation compare to the zaamo/zalrsc, zaamo/zalrsc should automatically append if a extension is available, which is new behavior and new ex

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

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 gimple_folder::redirect_call from > gimple * to gcall *. The motivation for this is that so far, most callers of > the function had be

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

Hi! So much manual stuff needed, sigh. On Fri, Jul 19, 2024 at 01:04:12PM -0700, Carl Love wrote: > gcc/ChangeLog: >     * config/rs6000/altivec.md (vsdb_): Change >     define_insn iterator to VEC_IC. >From VI2 (a nothing-saying name) to VEC_IC (also a nonsensical name). Maybe VEC_IC should ha

ping Re: [patch, libgfortran] PR105361 Incorrect end-of-file condition for derived-type I/O

On 7/22/24 8:13 AM, Jerry D wrote: Hi all, The attached patch fixes this by avoiding looking for and avoiding the EOF condition in the parent READ after returning from the child IO process. I could not think of a simple test case yet since the problem occurred only when redirecting the input

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

On Tue, Jul 23, 2024 at 04:26:43PM -0500, 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

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

On 7/24/24 12:06 PM, Segher Boessenkool wrote: > On Tue, Jul 23, 2024 at 04:26:43PM -0500, Peter Bergner wrote: >> On 7/19/24 3:04 PM, Carl Love wrote: >>> (define_insn "vsdb_" >>> - [(set (match_operand:VI2 0 "register_operand" "=v") >>> - (unspec:VI2 [(match_operand:VI2 1 "register_operand" "v"

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

On 7/24/24 12:03 PM, Segher Boessenkool wrote: >> +/* { dg-options "-mdejagnu-cpu=power10 -save-temps" } */ > > Why the -save-temps? Always document it if you want that for something, > but never put it in the testcase if not. A leftover from development? I can answer this one. :-). Since th

[committed][rtl-optimization/116037] Explicitly track if a destination was skipped in ext-dce

So this has been in the hopper since the first bugs were reported against ext-dce. It'd been holding off committing as I was finding other issues in terms of correctness of live computations. There's still problems in that space, but I think it's time to push this chunk forward. I'm marking

[PATCH] c++: Mostly concepts related formatting fixes

Hi! When playing with P2963R3, while reading and/or modifying code I've fixed various comment or code formatting issues (and in 3 spots also comment wording), but including that in the WIP P2963R3 patch made that patch totally unreadable because these changes were 4 times the size of the actual co

Re: [PATCH] c++: Mostly concepts related formatting fixes

On 7/24/24 1:33 PM, Jakub Jelinek wrote: Hi! When playing with P2963R3, while reading and/or modifying code I've fixed various comment or code formatting issues (and in 3 spots also comment wording), but including that in the WIP P2963R3 patch made that patch totally unreadable because these cha

[PATCH 0/5] RISC-V: Enable stack-clash protection

Hi All, This patch series implements stack-clash protection for RISC-V using 4K probes as default. The non-vector implementation is based on AArch64’s as the generated stack frame is similar. The tests are also adapted from AArch64. Thanks, Raphael Raphael Moreira Zinsly (5): RISC-V: Small st

[PATCH 1/5] RISC-V: Small stack tie changes

Enable the register used by riscv_emit_stack_tie () to be passed as an argument so we can tie the stack with other registers besides hard_frame_pointer_rtx. Also don't allow operand 1 of stack_tie to be optimized to sp in preparation for the stack clash protection support. gcc/ChangeLog: *

[PATCH 2/5] RISC-V: Move riscv_v_adjust_scalable_frame

Move riscv_v_adjust_scalable_frame () in preparation for the stack clash protection support. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_v_adjust_scalable_frame): Move closer to riscv_expand_prologue. --- gcc/config/riscv/riscv.cc | 62 +++

[PATCH 4/5] RISC-V: Add support to vector stack-clash protection

Adds basic support to vector stack-clash protection using a loop to do the probing and stack adjustments. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_allocate_and_probe_stack_loop): New function. (riscv_v_adjust_scalable_frame): Add stack-clash protection support.

[PATCH 5/5] RISC-V: Enable stack clash in alloca

Add the TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE to riscv in order to enable stack clash protection when using alloca. The code and tests are the same used by aarch64. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_compute_frame_info): Update outgoing args size.

[PATCH 3/5] RISC-V: Stack-clash protection implemention

This implements stack-clash protection for riscv, with riscv_allocate_and_probe_stack_space being based of aarch64_allocate_and_probe_stack_space from aarch64's implementation. We enforce the probing interval and the guard size to always be equal, their default value is 4Kb which is riscv page size

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

On Wed, Jul 24, 2024 at 12:12:05PM -0500, Peter Bergner wrote: > On 7/24/24 12:06 PM, Segher Boessenkool wrote: > I thought we always wanted the predicate to match the constraint being used? Predicates and constraints have different purposes, and are used at different times (typically). Everythin

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

On Wed, Jul 24, 2024 at 12:16:33PM -0500, Peter Bergner wrote: > > On 7/24/24 12:03 PM, Segher Boessenkool wrote: > >> +/* { dg-options "-mdejagnu-cpu=power10 -save-temps" } */ > > > > Why the -save-temps? Always document it if you want that for something, > > but never put it in the testcase if

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

Segher: Thanks for the review, a few questions... On 7/24/24 10:03 AM, Segher Boessenkool wrote: Hi! So much manual stuff needed, sigh. On Fri, Jul 19, 2024 at 01:04:12PM -0700, Carl Love wrote: gcc/ChangeLog:     * config/rs6000/altivec.md (vsdb_): Change     define_insn iterator to VEC_I

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

Hi! On Wed, Jul 24, 2024 at 11:38:11AM -0700, Carl Love wrote: > On 7/24/24 10:03 AM, Segher Boessenkool wrote: > >So much manual stuff needed, sigh. > > > >On Fri, Jul 19, 2024 at 01:04:12PM -0700, Carl Love wrote: > >>gcc/ChangeLog: > >>     * config/rs6000/altivec.md (vsdb_): Change > >>     de

Re: [PATCH v3 2/2] Prevent divide-by-zero

On 7/24/2024 3:52 AM, Richard Biener wrote: On Wed, Jul 24, 2024 at 1:31 AM Edwin Lu wrote: On 7/23/2024 11:20 AM, Richard Sandiford wrote: Edwin Lu writes: On 7/23/2024 4:56 AM, Richard Biener wrote: On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu wrote: Hi Richard, On 5/31/2024 1:48 AM, Ri

Re: [PATCH v3 2/2] Prevent divide-by-zero

On 7/24/2024 3:03 AM, Robin Dapp wrote: Thanks for the explanation! I have a few clarification questions about this. If I understand correctly, B would represent the number of elements the vector can have (for 128b vector operating on 32b elements, B == 4, but if operating on 64b elements B ==

Re: [PATCH v3 2/2] Prevent divide-by-zero

On 7/24/2024 3:03 AM, Robin Dapp wrote: Thanks for the explanation! I have a few clarification questions about this. If I understand correctly, B would represent the number of elements the vector can have (for 128b vector operating on 32b elements, B == 4, but if operating on 64b elements B ==

Re: [PATCH 1/2] cp/coroutines: do not rewrite parameters in unevaluated contexts

On 7/23/24 7:41 PM, Arsen Arsenović wrote: It is possible to use parameters of a parent function of a lambda in unevaluated contexts without capturing them. By not capturing them, we work around the usual mechanism we use to prevent rewriting captured parameters. Prevent this by simply skipping

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

On 7/23/24 7:41 PM, Arsen Arsenović wrote: co_await expressions are nearly calls to Awaitable::await_resume, and, as such, should inherit its nodiscard. A discarded co_await expression should, hence, act as if its call to await_resume was discarded. CO_AWAIT_EXPR trees do conveniently contain t

[PATCH] Use add_name_and_src_coords_attributes in modified_type_die

While working on a patch to the Ada compiler, I found a spot in dwarf2out.cc that calls add_name_attribute where a call to add_name_and_src_coords_attributes would be better, because the latter respects DECL_NAMELESS. gcc * dwarf2out.cc (modified_type_die): Call add_name_and_src_c

[PATCH 1/2] libstdc++: Move std::optional assertions out of _M_get()

Tested x86_64-linux. Any reason not to do this? I don't think the assertions are useful to catch implementation bugs where we access the contained value without checking it - we should use tests for that. -- >8 -- Currently we implement the precondition for accessing the contained value of a std

[PATCH 2/2] libstdc++: Use _M_get() in std::optional internals

Tested x86_64-linux. -- >8 -- Now that _base::_M_get() doesn't check the precondition, we can use _M_get() instead of operator*() for the internal uses where we've already checked the precondition holds. Add a using-declaration so that we don't need to lookup _M_get in the dependent base class,

[PATCH] libstdc++: Use concepts to simplify std::optional base classes

Tested x86_64-linux. -- >8 -- In C++20 mode we can simplify some of the std::optional base class hierarchy using concepts. We can overload the destructor and copy constructor and move constructor with a trivial defaulted version and a constrained non-trivial version. This allows us to remove some

[PATCH 2/2] libstdc++: Implement LWG 3836 for std::optional bool conversions

Tested x86_64-linux. -- >8 -- libstdc++-v3/ChangeLog: * include/std/optional (optional): Constrain constructors to prevent problematic bool conversions, as per LWG 3836. * testsuite/20_util/optional/cons/lwg3836.cc: New test. --- libstdc++-v3/include/std/optional

[PATCH 1/2] libstdc++: Implement LWG 3836 for std::expected bool conversions

Tested x86_64-linux. -- >8 -- libstdc++-v3/ChangeLog: * include/std/expected (expected): Constrain constructors to prevent problematic bool conversions, as per LWG 3836. * testsuite/20_util/expected/lwg3836.cc: New test. --- libstdc++-v3/include/std/expected

[PATCH] libstdc++: Add noexcept to bad_expected_access members (LWG 4031)

Tested x86_64-linux. -- >8 -- libstdc++-v3/ChangeLog: * include/std/expected (bad_expected_access): Add noexcept to special member functions, as per LWG 4031. * testsuite/20_util/expected/bad.cc: Check for nothrow copy and move members. --- libstdc++-v3/include/s

Re: [PATCH 1/2] libstdc++: Move std::optional assertions out of _M_get()

On Wed, 24 Jul 2024 at 22:51, Jonathan Wakely wrote: > > Tested x86_64-linux. > > Any reason not to do this? I don't think the assertions are useful to > catch implementation bugs where we access the contained value without > checking it - we should use tests for that. Looks good to me. > The cu

Re: [PATCH 1/2] libstdc++: Move std::optional assertions out of _M_get()

On Wed, 24 Jul 2024 at 20:55, Ville Voutilainen wrote: > > On Wed, 24 Jul 2024 at 22:51, Jonathan Wakely wrote: > > > > Tested x86_64-linux. > > > > Any reason not to do this? I don't think the assertions are useful to > > catch implementation bugs where we access the contained value without > >

Re: [PATCH 1/2] libstdc++: Move std::optional assertions out of _M_get()

On Wed, 24 Jul 2024 at 20:58, Jonathan Wakely wrote: > > On Wed, 24 Jul 2024 at 20:55, Ville Voutilainen > wrote: > > > > On Wed, 24 Jul 2024 at 22:51, Jonathan Wakely wrote: > > > > > > Tested x86_64-linux. > > > > > > Any reason not to do this? I don't think the assertions are useful to > > >

  1   2   >