Re: [PATCH 1/2] MIPS: host_detect_local_cpu, init ret with concat [PR112759]

On Mon, Dec 18, 2023 at 11:44:21AM +0800, YunQiang Su wrote: > The function `reconcat` cannot append string(s) to NULL, > as the concat process will stop at the first NULL. > > Let's initialize `ret` with `concat (" ", NULL)`, then > it can be used by reconcat. > > gcc/ > > PR target/11275

[PATCH] tree-object-size: Robustify alloc_size attribute handling [PR113013]

Hi! The following testcase ICEs because we aren't careful enough with alloc_size attribute. We do check that such an argument exists (although wouldn't handle correctly functions with more than INT_MAX arguments), but didn't check that it is scalar integer, the ICE is trying to fold_convert a str

Patch: Remove unneeded double operation in libstdc++-v3/src/c++17/fs_path.cc

This is a small change to libstdc++ which does not change any behavior. This change has two, ihmo positive, implications: - The implicit conversion from double to int is avoided (Avoiding a warning). - No floating point number is used at all, which could be significant in some scenario

[committed] testsuite: Fix up abi-tag25a.C test for C++11

On Thu, Dec 14, 2023 at 07:59:26PM -0500, Patrick Palka wrote: > * g++.dg/abi/abi-tag25.C: New test. > * g++.dg/abi/abi-tag25a.C: New test. Line 11 of abi-tag25.C is wrapped in #if __cpp_variable_templates which isn't defined for -std=c++11, so we can't expect a warning in that case ei

Re: [PATCH] tree-object-size: Robustify alloc_size attribute handling [PR113013]

On Mon, Dec 18, 2023 at 9:35 AM Jakub Jelinek wrote: > > Hi! > > The following testcase ICEs because we aren't careful enough with > alloc_size attribute. We do check that such an argument exists > (although wouldn't handle correctly functions with more than INT_MAX > arguments), but didn't check

Re: [PATCH] RISC-V: Enable vect test for RV32

Hi Juzhe, > -} elseif [istarget riscv64-*-*] { > +} elseif [istarget riscv*-*-*] { > if [check_effective_target_riscv_v] { > lappend DEFAULT_VECTCFLAGS "--param" "riscv-vector-abi" > set dg-do-what-default run Yes, that's reasonable. A bit further down we have

Re: [PATCH] RISC-V: Fix natural regsize for fixed-vlmax of -march=rv64gc_zve32f

LGTM. Regards Robin

[PATCH V2] RISC-V: Enable vect test for RV32

gcc/testsuite/ChangeLog: * lib/target-supports.exp: Add RV32. --- gcc/testsuite/lib/target-supports.exp | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index bd38d72562d..370df10978d

Re: [PATCH V2] RISC-V: Enable vect test for RV32

LGTM. Regards Robin

[PATCH] RISC-V: Support one more overlap for wv instructions

For 'wv' instructions, e.g. vwadd.wv vd,vs2,vs1. vs2 has same EEW as vd. vs1 has smaller than vd. So, vs2 can overlap with vd, but vs1 can only overlap highest-number of vd when LMUL of vs1 is greater than 1. We already have supported overlap for vs1 LMUL >= 1. But I forget vs1 LMUL < 1, vs2 can

[committed] libgomp: Make libgomp.c/declare-variant-1.c test x86 specific

Hi! As written earlier, this test was written with the x86 specifics in mind and adding dg-final directives for it for other arches makes it unreadable. If a declare variant call can be resolved in gimple already as in the aarch64 or gcn cases, it can be done in gcc.dg/gomp/ and I believe we have

[PATCH V2] RISC-V: Support one more overlap for wv instructions

For 'wv' instructions, e.g. vwadd.wv vd,vs2,vs1. vs2 has same EEW as vd. vs1 has smaller than vd. So, vs2 can overlap with vd, but vs1 can only overlap highest-number of vd when LMUL of vs1 is greater than 1. We already have supported overlap for vs1 LMUL >= 1. But I forget vs1 LMUL < 1, vs2 can

Re: [PATCH] RISC-V: Support one more overlap for wv instructions

Update in V2 with more information in commit log: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640863.html juzhe.zh...@rivai.ai From: Juzhe-Zhong Date: 2023-12-18 18:59 To: gcc-patches CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong Subject: [PATCH] RISC-V: Support

[PATCH] c/111975 - GIMPLE FE dumping and parsing of TARGET_MEM_REF

The following adds dumping of TARGET_MEM_REF in -gimple form and adds parsing of it to the GIMPLE FE. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR c/111975 gcc/c/ * gimple-parser.cc (c_parser_gimple_postfix_expression): Parse TARGET_MEM_REF extended oper

[PATCH 0/2] arm: Add support for MVE Tail-Predicated Low Overhead Loops

Resending series to make use of the Linaro pre-commit CI in patchworks. Andre Vieira (2): arm: Add define_attr to to create a mapping between MVE predicated and unpredicated insns arm: Add support for MVE Tail-Predicated Low Overhead Loops -- 2.17.1

[PATCH 1/2] arm: Add define_attr to to create a mapping between MVE predicated and unpredicated insns

Re-sending Stam's first patch, same as: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635301.html Hopefully patchworks can pick this up :) diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h index a9c2752c0ea..0b0e8620717 100644 --- a/gcc/config/arm/arm.h +++ b/gcc/config/arm/arm.

[PATCH 2/2] arm: Add support for MVE Tail-Predicated Low Overhead Loops

Reworked Stam's patch after comments in: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640362.html The original gcc ChangeLog remains unchanged, but I did split up some tests so here is the testsuite ChangeLog. gcc/testsuite/ChangeLog: * gcc.target/arm/lob.h: Update framework

Re: [PATCH V2] RISC-V: Support one more overlap for wv instructions

OK. Regards Robin

Re: [PATCH,doc] install: Drop hppa*-hp-hpux10, remove old notes on hppa*-hp-hpux11

On Sun, 17 Dec 2023, John David Anglin wrote: > The sentence about 64-bit libffi for hpux also can be removed. I ported > it a few years ago. Thanks! I made this change on top and pushed the resulting changeset. >> (I believe it would be great if you could have a look at that part of the >> ins

[PATCH] middle-end: Call negate_rtx instead of simplify_gen_unary expanding rotate shift [PR113033]

With simplify_gen_unary we end up with a not fully expanded RTX like (set (reg:SI 90) (and:SI (neg:SI (reg:SI 80)) (const_int 63))) Then it will cause an ICE with unrecognizable insn. gcc/ChangeLog: PR middle-end/113033 * expmed.cc (expand_shift_1): When expanding rotate shi

[PATCH] LoongArch: Expand left rotate to right rotate with negated amount

gcc/ChangeLog: * config/loongarch/loongarch.md (rotl3): New define_expand. * config/loongarch/simd.md (vrotl3): Likewise. (rotl3): Likewise. gcc/testsuite/ChangeLog: * gcc.target/loongarch/rotl-with-rotr.c: New test. * gcc.target/loongarch/rotl-wit

[PATCH] middle-end/111975 - dump -> GIMPLE FE roundtrip improvements

The following improves the manual work needed to make a -gimple dump valid input to the GIMPLE FE. First of all it recognizes the 'sizetype' tree and dumps it as __SIZETYPE__, then it changes dumping vector types without name from 'vector(n) T' to 'T [[gnu::vector_size(n')]]' which we can parse in

Re: [PATCH] middle-end/111975 - dump -> GIMPLE FE roundtrip improvements

On Mon, Dec 18, 2023 at 03:08:49PM +0100, Richard Biener wrote: > The following improves the manual work needed to make a -gimple dump > valid input to the GIMPLE FE. First of all it recognizes the 'sizetype' > tree and dumps it as __SIZETYPE__, then it changes dumping vector types > without name

Re: [PATCH] middle-end/111975 - dump -> GIMPLE FE roundtrip improvements

On Mon, 18 Dec 2023, Jakub Jelinek wrote: > On Mon, Dec 18, 2023 at 03:08:49PM +0100, Richard Biener wrote: > > The following improves the manual work needed to make a -gimple dump > > valid input to the GIMPLE FE. First of all it recognizes the 'sizetype' > > tree and dumps it as __SIZETYPE__, t

[PATCH] SECURITY.txt: Drop "exploitable" in reference to hardening issues

The "exploitable vulnerability" may lead to a misunderstanding that missed hardening issues are considered vulnerabilities, just that they're not exploitable. This is not true, since while hardening bugs may be security-relevant, the absence of hardening does not make a program any more vulner

Re: [committed] amdgcn: XNACK support

Hi Andrew! On 2023-12-13T15:46:45+, Andrew Stubbs wrote: > Some AMD GCN devices support an "XNACK" mode in which the device can > handle page-misses (and maybe other traps in memory instructions), but > it's not completely invisible to software. > > We need this now to support OpenMP Unified

Re: [PATCH V4 3/5] OpenMP: Use enumerators for names of trait-sets and traits

Hi Sandra, On 17.12.23 20:02, Sandra Loosemore wrote: This patch introduces enumerators to represent trait-set names and trait names, which makes it easier to use tables to control other behavior and for switch statements to dispatch on the tags. The tags are stored in the same place in the TRE

Re: [PATCH] middle-end: Call negate_rtx instead of simplify_gen_unary expanding rotate shift [PR113033]

On 12/18/23 06:42, Xi Ruoyao wrote: With simplify_gen_unary we end up with a not fully expanded RTX like (set (reg:SI 90) (and:SI (neg:SI (reg:SI 80)) (const_int 63))) Then it will cause an ICE with unrecognizable insn. gcc/ChangeLog: PR middle-end/113033 * expmed.cc (

[COMMITTED] SCCP: Fix ODR issues when compiling with LTO [PR 113054}

The problem here is that in C++ structs and classes have a linkage too so the type vertex is not considered local to the TU but will conflict with the globally defined one in graphds.h. The simple way to fix this is to wrap the ones defined locally in gimple-ssa-sccopy.cc inside an anonymous names

[PATCH] tree-object-size: Always set computed bit for bdos [PR113012]

It is always safe to set the computed bit for dynamic object sizes at the end of collect_object_sizes_for because even in case of a dependency loop encountered in nested calls, we have an SSA temporary to actually finish the object size expression. The reexamine pass for dynamic object sizes is on

Re: [PATCH] middle-end: Call negate_rtx instead of simplify_gen_unary expanding rotate shift [PR113033]

On Mon, 2023-12-18 at 08:39 -0700, Jeff Law wrote: > > > On 12/18/23 06:42, Xi Ruoyao wrote: > > With simplify_gen_unary we end up with a not fully expanded RTX like > > > > (set (reg:SI 90) (and:SI (neg:SI (reg:SI 80)) (const_int 63))) > > > > Then it will cause an ICE with unrecognizable

[PATCH] enable ATOMIC_COMPARE_EXCHANGE opt for floating type or types contains padding

Hi, I noticed PR71716 and I want to enable ATOMIC_COMPARE_EXCHANGE internal-fn optimization for floating type or types contains padding (e.g., long double). Please tell me if I happen to make any mistakes, Thanks! Firstly, about the concerns of sNaNs float/double value, it seems work well and

[PATCH] gimple-fold.cc: enable ATOMIC_COMPARE_EXCHANGE opt for floating type or types contain padding

gcc/ChangeLog: * gimple-fold.cc (optimize_atomic_compare_exchange_p): enable for SCALAR_FLOAT_TYPE_P type of expected var, or if TYPE_PRECISION is different from mode's bitsize (fold_builtin_atomic_compare_exchange): if TYPE_PRECISION is different from mode'

libgrust: 'AM_ENABLE_MULTILIB' only for target builds [PR113056] (was: [PATCH v2 2/4] libgrust: Add libproc_macro and build system)

Hi! > --- a/libgrust/configure.ac > +++ b/libgrust/configure.ac > -# AM_ENABLE_MULTILIB(, ..) > +AM_ENABLE_MULTILIB(, ..) Such a change was applied eventually, and is necessary for target builds -- but potentially harmful for host builds. OK to push the attached "libgrust: 'AM_ENABLE_MULTILIB'

[x86 PATCH] Improved TImode (128-bit) integer constants on x86_64.

This patch fixes two issues with the handling of 128-bit TImode integer constants in the x86_64 backend. The main issue is that GCC always tries to load 128-bit integer constants via broadcasts to vector SSE registers, even if the result is required in general registers. This is seen in the two

Re: [PATCH] middle-end: Call negate_rtx instead of simplify_gen_unary expanding rotate shift [PR113033]

On Tue, Dec 19, 2023 at 12:48:46AM +0800, Xi Ruoyao wrote: > > > gcc/ChangeLog: > > > > > > PR middle-end/113033 > > > * expmed.cc (expand_shift_1): When expanding rotate shift, call > > > negate_rtx instead of simplify_gen_unary (NEG, ...). > > > The key difference being that using negate_

[PATCH] Fortran: update DATE_AND_TIME intrinsic for Fortran 2018 [PR96580]

Dear all, starting with Fortran 2018, DATE_AND_TIME allowed a non-default integer VALUES argument. While gfortran accepts this silently, this failed at runtime because the library implementation beyond kind=4 and kind=8 was missing. Futhermore, the standard effectively requires that the integer

Re: [PATCH] c-family: Use -Wdiscarded-qualifiers for ignored qualifiers in __atomic_*

On Sun, 17 Dec 2023, Florian Weimer wrote: > This matches other compiler diagnostics. No test updates are needed > because c-c++-common/pr95378.c does not match a specific -W option. > > Fixes commit d2384b7b24f8557b66f6958a05ea99ff4307e75c ("c-family: > check qualifiers of arguments to __atomic

Re: RFC -- targets with unsigned bifields

On Sat, 16 Dec 2023, Jeff Law wrote: > I tracked this down to the port unconditionally adding -funsigned-bitfields to > CC1_SPEC. According to the comment it's how the ABI is defined for the mcore > targets. We explicitly document (under Non-bugs in trouble.texi) that we don't do this, and -fun

Re: [PATCH] c++: Check null pointer deref when calling memfn in constexpr [PR102420]

On 12/17/23 16:51, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? An alternative approach for the lambda issue would be to modify 'maybe_add_lambda_conv_op' to not pass a null pointer, but I wasn't sure what the best approach for that would be. I don't

Re: RFC -- targets with unsigned bifields

On 12/18/23 11:32, Joseph Myers wrote: On Sat, 16 Dec 2023, Jeff Law wrote: I tracked this down to the port unconditionally adding -funsigned-bitfields to CC1_SPEC. According to the comment it's how the ABI is defined for the mcore targets. We explicitly document (under Non-bugs in troubl

[Committed] IBM Z: Cover weak symbols with -munaligned-symbols

With the recently introduced -munaligned-symbols option byte-sized variables which are resolved externally are considered to be potentially misaligned. However, this should rather also be applied to symbols which resolve locally if they are weak. Done with this patch. Committed to mainline. gcc/C

Re: [PATCH v3] libcpp: add function to check XID properties

On Fri, 8 Sep 2023, Arthur Cohen wrote: > + if (c < 0x80) > + { > +if (('A' <= c && c <= 'Z') || ('a' <= c && c <= 'z')) > + return CPP_XID_START | CPP_XID_CONTINUE; > +if (('0' <= c && c <= '9') || c == '_') > + return CPP_XID_CONTINUE; This may be an artifact of how the patch was ma

[PATCH] c: Split -Wcalloc-transposed-args warning from -Walloc-size, -Walloc-size fixes

Hi! The following patch changes -Walloc-size warning to no longer warn about int *p = calloc (1, sizeof (int));, because as discussed earlier, the size is IMNSHO sufficient in that case, for alloc_size with 2 arguments warns if the product of the 2 arguments is insufficiently small. Also, it warn

Re: [PATCH] Fortran: update DATE_AND_TIME intrinsic for Fortran 2018 [PR96580]

On Mon, Dec 18, 2023 at 07:11:59PM +0100, Harald Anlauf wrote: > Dear all, > > starting with Fortran 2018, DATE_AND_TIME allowed a non-default > integer VALUES argument. > > While gfortran accepts this silently, this failed at runtime > because the library implementation beyond kind=4 and kind=8

[PATCH] c++: [[deprecated]] on template redecl [PR84542]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- The deprecated and unavailable attributes weren't working when used on a template redeclaration ultimately because the corresponding tree flags on the underlying decls weren't being merged across redeclaratio

[PATCH] fold-const: Handle AND, IOR, XOR with stepped vectors [PR112971].

Hi, found in PR112971, this patch adds folding support for bitwise operations of const duplicate zero vectors and stepped vectors. On riscv we have the situation that a folding would perpetually continue without simplifying because e.g. {0, 0, 0, ...} & {7, 6, 5, ...} would not fold to {0, 0, 0, .

[PATCH] c++: local class memfn synth from uneval context [PR113063]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here we first use and therefore synthesize the local class operator<=> from an unevaluated context, which inadvertently affects synthesization by causing functions used within the definition (such as the copy

[PATCH] c++: bad direct reference binding [PR113064]

Bootstrappde and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- When computing a direct conversion to reference type fails and yields a bad conversion, reference_binding incorrectly commits to that conversion rather than attempting a conversion via a temporary. This lead

Re: [PATCH] c++: [[deprecated]] on template redecl [PR84542]

On Mon, Dec 18, 2023 at 02:50:04PM -0500, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk? LGTM but... > -- >8 -- > > The deprecated and unavailable attributes weren't working when used on > a template redeclaration ultimately because the

Re: [PATCH] middle-end: Call negate_rtx instead of simplify_gen_unary expanding rotate shift [PR113033]

On Mon, 2023-12-18 at 18:45 +0100, Jakub Jelinek wrote: > On Tue, Dec 19, 2023 at 12:48:46AM +0800, Xi Ruoyao wrote: > > > > gcc/ChangeLog: > > > > > > > > PR middle-end/113033 > > > > * expmed.cc (expand_shift_1): When expanding rotate shift, call > > > > negate_rtx instea

Re: [PATCH] middle-end: Call negate_rtx instead of simplify_gen_unary expanding rotate shift [PR113033]

On Tue, Dec 19, 2023 at 04:01:52AM +0800, Xi Ruoyao wrote: > On Mon, 2023-12-18 at 18:45 +0100, Jakub Jelinek wrote: > > On Tue, Dec 19, 2023 at 12:48:46AM +0800, Xi Ruoyao wrote: > > > > > gcc/ChangeLog: > > > > > > > > > > PR middle-end/113033 > > > > > * expmed.cc (expand_shift_1):

Re: [PATCH] middle-end: Call negate_rtx instead of simplify_gen_unary expanding rotate shift [PR113033]

On Mon, 2023-12-18 at 21:15 +0100, Jakub Jelinek wrote: > > Then that seems like a bug in the loongarch vec_init pattern(s). > Those really don't have a predicate in any of the backends on the input > operand, so they need to force_reg it if it is something it can't handle. > I've looked e.g. at i

[committed] i386: Eliminate redundant compare between set{z, nz} and j{z, nz}

Eliminate redundant compare between set{z,nz} and j{z,nz}: setz %al; test %al,%al; jz <...> -> setz %al; jnz <...> and setnz %al, test %al,%al; jz <...> -> setnz %al; jz <...>. We can use the original Zero-flag value instead of setting the temporary register and testing it for zero. gcc/ChangeLog

[PATCH RFC] c++/modules: __class_type_info and modules

Tested x86_64-pc-linux-gnu. Does this make sense? Did you have another theory about how to merge these? -- 8< -- Doing a dynamic_cast in both TUs broke because we were declaring a new __class_type_info in _b that conflicted with the one imported in the global module from _a. lookup_elaborated_

Re: [PATCH] c++: [[deprecated]] on template redecl [PR84542]

On 12/18/23 14:56, Marek Polacek wrote: On Mon, Dec 18, 2023 at 02:50:04PM -0500, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? LGTM but... -- >8 -- The deprecated and unavailable attributes weren't working when used on a template red

Re: [PATCH] c++: bad direct reference binding [PR113064]

On 12/18/23 14:50, Patrick Palka wrote: Bootstrappde and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- When computing a direct conversion to reference type fails and yields a bad conversion, reference_binding incorrectly commits to that conversion rather than at

Re: [PATCH] c++: local class memfn synth from uneval context [PR113063]

On 12/18/23 14:50, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- Here we first use and therefore synthesize the local class operator<=> from an unevaluated context, which inadvertently affects synthesization by causing funct

Re: [PATCH 1/2] c++: refine dependent_alias_template_spec_p [PR90679]

On 12/15/23 14:06, Patrick Palka wrote: On Mon, 11 Sep 2023, Patrick Palka wrote: On Thu, 1 Jun 2023, Patrick Palka wrote: For a complex alias template-id, dependent_alias_template_spec_p returns true if any template argument of the template-id is dependent. This predicate indicates that sub

Re: [PATCH RFC] c++/modules: __class_type_info and modules

On 12/18/23 16:31, Jason Merrill wrote: Tested x86_64-pc-linux-gnu. Does this make sense? Did you have another theory about how to merge these? Why isn't push_abi_namespace doing the right setup here? (and I think get_global_binding might be similarly problematic?) nathan -- 8< -- Doin

Re: [PATCH 2/2] c++: partial ordering and dep alias tmpl specs [PR90679]

On 12/15/23 14:07, Patrick Palka wrote: On Thu, 1 Jun 2023, Patrick Palka wrote: During partial ordering, we want to look through dependent alias template specializations within template arguments and otherwise treat them as opaque in other contexts (see e.g. r7-7116-g0c942f3edab108 and r11-701

Re: [PATCH RFC] c++/modules: __class_type_info and modules

On 12/18/23 16:57, Nathan Sidwell wrote: On 12/18/23 16:31, Jason Merrill wrote: Tested x86_64-pc-linux-gnu.  Does this make sense?  Did you have another theory about how to merge these? Why isn't push_abi_namespace doing the right setup here? (and I think get_global_binding might be similar

[pushed][PR112918][LRA]: Fixing IRA ICE on m68k

The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918 The patch was successfully bootstrapped and tested on x86-64, aarch64, and ppc64. The patch affects a sensitive part of LRA.  So I will monitor that the commit does not create serious failures on other targets. If

Re: [PATCH] Add support for function attributes and variable attributes

Ping David. :) Le sam. 9 déc. 2023 à 12:12, Guillaume Gomez a écrit : > > Added it. > > Le jeu. 7 déc. 2023 à 18:13, Antoni Boucher a écrit : > > > > It seems like you forgot to prefix the commit message with "libgccjit: > > ". > > > > On Thu, 2023-11-30 at 10:55 +0100, Guillaume Gomez wrote: >

[PATCH] aarch64: Fix parens in aarch64_stp_reg_operand [PR113061]

In r14-6603-gfcdd2757c76bf925115b8e1ba4318d6366dd6f09 I messed up the parentheses in aarch64_stp_reg_operand, the indentation shows the intended nesting of the conditions. This patch fixes that. This fixes PR113061 which shows IRA substituting (const_int 1) into a writeback stp pattern as a resul

Re: [PATCH] fold-const: Handle AND, IOR, XOR with stepped vectors [PR112971].

Thanks Robin send initial patch to fix this ICE bug. CC to Richard S, Richard B, and Andrew. Thanks. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-12-19 03:50 To: gcc-patches CC: rdapp.gcc; Li, Pan2; juzhe.zh...@rivai.ai Subject: [PATCH] fold-const: Handle AND, IOR, XOR with stepped vecto

Re: [PATCH 1/2] MIPS: host_detect_local_cpu, init ret with concat [PR112759]

Jakub Jelinek 于2023年12月18日周一 16:10写道： > > On Mon, Dec 18, 2023 at 11:44:21AM +0800, YunQiang Su wrote: > > The function `reconcat` cannot append string(s) to NULL, > > as the concat process will stop at the first NULL. > > > > Let's initialize `ret` with `concat (" ", NULL)`, then > > it can be us

[pushed] libstdc++: Make ranges::to closure objects SFINAE-friendly [PR112802]

This also happens to fix composition of these closure objects. PR libstdc++/112802 PR libstdc++/113068 libstdc++-v3/ChangeLog: * include/std/ranges (__detail::_To::operator()): Add constraints. (__detail::_To2::operator()): Likewise. * testsuite/std/ranges

Re: [pushed][PR112918][LRA]: Fixing IRA ICE on m68k

On 12/18/23 15:16, Vladimir Makarov wrote: The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918 The patch was successfully bootstrapped and tested on x86-64, aarch64, and ppc64. The patch affects a sensitive part of LRA.  So I will monitor that the commit does no

Re: [PATCH] RISC-V: Add required_extensions in function_group

Thanks for refactor it. You can commit it today. Thanks. juzhe.zh...@rivai.ai From: Feng Wang Date: 2023-12-18 11:28 To: gcc-patches CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang Subject: [PATCH] RISC-V: Add required_extensions in function_group In order to add other vector related ext

[committed] RISC-V: Add required_extensions in function_group

In order to add other vector related extensions in the future, this patch add one more parameter in the function_group_info, it will be used to determine whether intrinsic registration processing is required. gcc/ChangeLog: * config/riscv/riscv-vector-builtins-functions.def (REQUIRED_EXT

[PATCH v2] MIPS: Put the ret to the end of args of reconcat [PR112759]

The function `reconcat` cannot append string(s) to NULL, as the concat process will stop at the first NULL. Let's always put the `ret` to the end, as it may be NULL. We keep use reconcat here, due to that reconcat can make it easier if we add more hardware features detecting, for example by hwcap.

Go patch committed: Move lowering pass after check types pass

This Go frontend patch moves the lowering pass after the type determination and the type checking passes. This lets us simplify some of the code that determines the type of an expression, which previously had to work correctly both before and after type determination. I'm doing this to help with

[PATCH] testsuite: Fix cpymem-2.c dump checks under different riscv-sim for RVV.

From: xuli gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/cpymem-2.c: Fix checks. --- .../gcc.target/riscv/rvv/base/cpymem-2.c | 44 ++- 1 file changed, 33 insertions(+), 11 deletions(-) diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/cpymem-2.c b/gcc/t

Re: [PATCH] testsuite: Fix cpymem-2.c dump checks under different riscv-sim for RVV.

OK。 juzhe.zh...@rivai.ai From: Li Xu Date: 2023-12-19 09:44 To: gcc-patches CC: kito.cheng; palmer; juzhe.zhong; xuli Subject: [PATCH] testsuite: Fix cpymem-2.c dump checks under different riscv-sim for RVV. From: xuli gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/cpymem-2

Re: [Patchv2, rs6000] Correct definition of macro of fixed point efficient unaligned

Hi Haochen, on 2023/12/18 10:43, HAO CHEN GUI wrote: > Hi, > The patch corrects the definition of > TARGET_EFFICIENT_OVERLAPPING_UNALIGNED and replace it with the call of > slow_unaligned_access. > > Compared with last version, > https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640076.

Re: [pushed][PR112918][LRA]: Fixing IRA ICE on m68k

On 12/18/23 17:05, Jeff Law wrote: On 12/18/23 15:16, Vladimir Makarov wrote: The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918 The patch was successfully bootstrapped and tested on x86-64, aarch64, and ppc64. The patch affects a sensitive part of LRA.  So I

Re: [PATCH] strub: use opt_for_fn during ipa

On Dec 15, 2023, Richard Biener wrote: > You have to be generally careful when working within IPA > with function bodies without push/pop_cfun around that, several APIs > have variants with struct function sepcified, using the wrong one > will get you a NULL cfun which _some_ of them handle grace

[Committed] RISC-V: Remove 256/512/1024 VLS vectors

Since https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2e7abd09621a4401d44f4513adf126bce4b4828b we only allow VLSmodes with size <= TARGET_MIN_VLEN * TARGET_MAX_LMUL. So when -march=rv64gcv default LMUL = 1, we don't have VLS modes of 256/512/1024 vectors. Disable them in vect test which fixes the

[Committed] RISC-V: Fix FAIL of dynamic-lmul2-7.c

Fix this FAIL: FAIL: gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-7.c scan-tree-dump-times vect "Maximum lmul = 2" 1 gcc/testsuite/ChangeLog: * gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-7.c: Adapt test. --- gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-7.c | 2 +- 1

[PATCH] testsuite: Fix dump checks under different riscv-sim for RVV.

From: xuli gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/cpymem-1.c: Fix checks under medany. * gcc.target/riscv/rvv/base/cpymem-strategy-3.c: Fix checks. * gcc.target/riscv/rvv/base/cpymem-strategy-4.c: Ditto. --- .../gcc.target/riscv/rvv/base/cpymem-1.c | 2

[PATCH] Optimize A < B ? A : B to MIN_EXPR.

Similar for A < B ? B : A to MAX_EXPR. There're codes in the frontend to optimize such pattern but failed to handle testcase in the PR since it's exposed at gimple level when folding backend builtins. pr95906 now can be optimized to MAX_EXPR as it's commented in the testcase. // FIXME: this shoul

Re: [PATCH] testsuite: Fix dump checks under different riscv-sim for RVV.

ok Replied Message FromLi XuDate12/19/2023 13:31 Togcc-patches@gcc.gnu.org Cckito.ch...@gmail.com,pal...@dabbelt.com,juzhe.zh...@rivai.ai,xuliSubject[PATCH] testsuite: Fix dump checks under different riscv-sim for RVV.

Re: Re: [PATCH] testsuite: Fix dump checks under different riscv-sim for RVV.

Committed, thanks juzhe. xu...@eswincomputing.com From: juzhe.zhong Date: 2023-12-19 14:01 To: Li Xu CC: gcc-patches@gcc.gnu.org; kito.ch...@gmail.com; pal...@dabbelt.com; xuli Subject: Re: [PATCH] testsuite: Fix dump checks under different riscv-sim for RVV. ok Replied Message From

Re: [Patchv2, rs6000] Clean up pre-checkings of expand_block_compare

Hi Haochen, on 2023/12/18 10:44, HAO CHEN GUI wrote: > Hi, > This patch cleans up pre-checkings of expand_block_compare. It does > 1. Assert only P7 above can enter this function as it's already guard > by the expand. > 2. Return false when optimizing for size. > 3. Remove P7 processor test as o

[PATCH 0/2] LoongArch: Fix PR113033 and clean up code

Superseds https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640871.html. Per Jakub's response, vec_init patterns do not have a predicate on the input operand so the operand can be *anything*. It's not safe to simply move it into an reg, and we have to use force_reg instead. The code clean

[PATCH 1/2] LoongArch: Use force_reg instead of gen_reg_rtx + emit_move_insn in vec_init expander [PR113033]

Jakub says: Then that seems like a bug in the loongarch vec_init pattern(s). Those really don't have a predicate in any of the backends on the input operand, so they need to force_reg it if it is something it can't handle. I've looked e.g. at i386 vec_init and that is exactly w

[PATCH 2/2] LoongArch: Clean up vec_init expander

Non functional change, clean up the code. gcc/ChangeLog: * config/loongarch/loongarch.cc (loongarch_expand_vector_init_same): Remove "temp2" and reuse "temp" instead. (loongarch_expand_vector_init): Use gcc_unreachable () instead of gcc_assert (0), and fix

Re: [PATCH] c: Split -Wcalloc-transposed-args warning from -Walloc-size, -Walloc-size fixes

Am Montag, dem 18.12.2023 um 20:14 +0100 schrieb Jakub Jelinek: > Hi! > > The following patch changes -Walloc-size warning to no longer warn > about int *p = calloc (1, sizeof (int));, because as discussed earlier, > the size is IMNSHO sufficient in that case, for alloc_size with 2 > arguments war

Re: [PATCH 0/2] LoongArch: Fix PR113033 and clean up code

We will read and test these patches as soon as possible. Thanks! 在 2023/12/19 下午2:59, Xi Ruoyao 写道: Superseds https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640871.html. Per Jakub's response, vec_init patterns do not have a predicate on the input operand so the operand can be *anythin

Re: [PATCH v2] extend.texi: Fix typos in LSX intrinsics

LGTM! Thanks for the revision.:-) 在 2023/12/13 下午11:26, Jiajie Chen 写道: Several typos have been found and fixed: missing semicolons, using variable name instead of type, duplicate functions and wrong types. gcc/ChangeLog: * doc/extend.texi(__lsx_vabsd_di): remove extra `i' in name.