[PATCH] c++/modules: Merge default arguments [PR99274]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? I tried to implement a remapping of the slots for TARGET_EXPRs for the FIXME but I wasn't able to work out how to do so effectively. Given that I doubt this will be a common issue I felt probably easiest to leave it for now and focu

[PATCH v2] ASAN: call initialize_sanitizer_builtins for hwasan [PR115205]

Sometimes initialize_sanitizer_builtins is not called before emitting the asan builtins with hwasan. In the case of the bug report, there was a path with the fortran front-end where it was not called. So let's call it in asan_instrument before calling transform_statements and from hwasan_finish_fil

Re: PING: [PATCH] x86: Update BB_HEAD when aligning BB_HEAD

On Sun, Aug 11, 2024 at 6:52 PM Hongtao Liu wrote: > > On Mon, Aug 12, 2024 at 6:59 AM H.J. Lu wrote: > > > > On Thu, Aug 8, 2024 at 6:53 PM H.J. Lu wrote: > > > > > > When we emit .p2align to align BB_HEAD, we must update BB_HEAD. Otherwise > > > ENDBR will be inserted as the wrong place. > >

Re: [PATCH] rs6000: Add TARGET_P10_VECTOR for Power10 vector insns [PR116266]

Hi Segher & Peter, Thanks for your comments!! on 2024/8/10 05:43, Segher Boessenkool wrote: > On Fri, Aug 09, 2024 at 03:50:50PM -0500, Peter Bergner wrote: >> On 8/9/24 12:54 PM, Segher Boessenkool wrote: --- a/gcc/config/rs6000/altivec.md +++ b/gcc/config/rs6000/altivec.md @@ -62

RE: [PATCH] [x86] Mention _Float16 and __bf16 changes in GCC14.

> -Original Message- > From: Gerald Pfeifer > Sent: Saturday, August 10, 2024 6:33 PM > To: Liu, Hongtao > Cc: gcc-patches@gcc.gnu.org; crazy...@gmail.com; hjl.to...@gmail.com > Subject: Re: [PATCH] [x86] Mention _Float16 and __bf16 changes in GCC14. > > On Wed, 31 Jul 2024, liuhongt

Re: PING: [PATCH] x86: Update BB_HEAD when aligning BB_HEAD

On Mon, Aug 12, 2024 at 6:59 AM H.J. Lu wrote: > > On Thu, Aug 8, 2024 at 6:53 PM H.J. Lu wrote: > > > > When we emit .p2align to align BB_HEAD, we must update BB_HEAD. Otherwise > > ENDBR will be inserted as the wrong place. > > > > gcc/ > > > > PR target/116174 > > * config/i38

Re: [PATCH/RFC] LRA: Don't emit move for substituted CONSTATNT_P operand [PR116170]

Hi Vladimir, on 2024/8/10 01:47, Vladimir Makarov wrote: > > On 8/9/24 05:49, Kewen.Lin wrote: >> Hi, >> >> Commit r15-2084 exposes one ICE in LRA.  Firstly, before >> r15-2084 KFmode has 126 bit precision while V1TImode has 128 >> bit precision, so the subreg (subreg:V1TI (reg:KF 131) 0) is >> p

Re: [pushed][PATCH v1 2/2] LoongArch: Provide ashr lshr and ashl RTL pattern for vectors.

Pushed to r15-2879. 在 2024/8/8 下午2:47, Lulu Cheng 写道: We support vashr vlshr and vashl. However, in r15-1638 support optimize x < 0 ? -1 : 0 into (signed) x >> 31 and x < 0 ? 1 : 0 into (unsigned) x >> 31. To support this optimization, vector ashr lshr and ashl need to be implemented. gcc/Chang

Re: [pushed][PATCH v1 1/2] LoongArch: Drop vcond{,u} expanders.

Pushed to r15-2878. 在 2024/8/8 下午2:47, Lulu Cheng 写道: Optabs vcond{,u} will be removed for GCC 15. Since regtest shows no fallout, dropping the expanders, now. gcc/ChangeLog: PR target/114189 * config/loongarch/lasx.md (vcondu): Delete. (vcond): Likewise. * con

Re:[pushed] [PATCH v2] LoongArch: Use iorn and andn standard pattern names.

 Pushed to r15-2877. 在 2024/8/2 上午9:19, Lulu Cheng 写道: R15-1890 introduced new optabs iorc and andc, and its corresponding internal functions BIT_{ANDC,IORC}, and if targets defines such optabs for vector modes. And in r15-2258 the iorc and andc were renamed to iorn and andn. So we changed the

[PATCH v8 3/3] c: Add __lengthof__ operator

This operator is similar to sizeof but can only be applied to an array, and returns its length (number of elements). FUTURE DIRECTIONS: - We should make it work with array parameters to functions, and somehow magically return the length designator of the array, regardless of it being reall

[PATCH v8 1/3] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

The old name was misleading. While at it, also rename some temporary variables that are used with this function, for consistency. Link: https://inbox.sourceware.org/gcc-patches/9fffd80-dca-2c7e-14b-6c9b509a7...@redhat.com/T/#m2f661c67c8f7b2c405c8c7fc3152dd85dc729120 Cc: Gabriel Ravier Cc: Marti

[PATCH v8 2/3] Merge definitions of array_type_nelts_top()

There were two identical definitions, and none of them are available where they are needed for implementing __lengthof__. Merge them, and provide the single definition in gcc/tree.{h,cc}, where it's available for __lengthof__, which will be added in the following commit. gcc/ChangeLog: *

[PATCH v8 0/3] c: Add __lengthof__ operator

Hi! v8: - Reformat (simplify) change-log entries. - Improve wording of documentation. - Add link to LLVM issue in commit message. I've added a GitHub issue in the LLVM project reporting about the existence of this patch set: Have a lovely

PING: [PATCH] x86: Update BB_HEAD when aligning BB_HEAD

On Thu, Aug 8, 2024 at 6:53 PM H.J. Lu wrote: > > When we emit .p2align to align BB_HEAD, we must update BB_HEAD. Otherwise > ENDBR will be inserted as the wrong place. > > gcc/ > > PR target/116174 > * config/i386/i386.cc (ix86_align_loops): Update BB_HEAD when > aligning

Re: [PATCH] lra: emit caller-save register spills before call insn [PR116028]

Hi, On Fri, Aug 09, 2024 at 08:15:31PM -0700, Andrew Pinski wrote: > I had been wondering the same until I looked into it earlier today. > Linaro CI's does `--disable-bootstrap` and there was no extra > testsuite failures with the patch. > So Linaro CI's is not catching all the bugs that a develop

[PATCH 8/8] RISC-V: Add else operand to masked loads [PR115536].

This patch adds else operands to masked loads. Currently the default else operand predicate accepts "undefined" (i.e. SCRATCH) as well as all-ones values. Note that this series introduces a large number of new RVV FAILs for riscv. All of them are due to us not being able to elide redundant vec_c

[PATCH 7/8] i386: Add else operand to masked loads.

This patch adds a zero else operand to masked loads, in particular the masked gather load builtins that are used for gather vectorization. gcc/ChangeLog: * config/i386/i386-expand.cc (ix86_expand_special_args_builtin): Add else-operand handling. (ix86_expand_builtin): Ditt

[PATCH 6/8] gcn: Add else operand to masked loads.

This patch adds a zero else operand to the masked loads. gcc/ChangeLog: * config/gcn/predicates.md (maskload_else_operand): New predicate. * config/gcn/gcn-valu.md: Use new predicate. --- gcc/config/gcn/gcn-valu.md | 6 -- gcc/config/gcn/predicates.md | 3 +++ 2 fil

[PATCH 3/8] tree-ifcvt: Enforce zero else value after maskload.

When predicating a load we implicitly assume that the else value is zero. In order to formalize this this patch queries the target for its supported else operand and uses that for the maskload call. Subsequently, if the else operand is nonzero, a cond_expr enforcing a zero else value is emitted.

[PATCH 4/8] vect: Add maskload else value support.

This patch adds an else operand to vectorized masked load calls. The current implementation adds else-value arguments to the respective target-querying functions that is used to supply the vectorizer with the proper else value. Right now, the only spot where a zero else value is actually enforced

[PATCH 5/8] aarch64: Add masked-load else operands.

This adds zero else operands to masked loads and their intrinsics. I needed to adjust more than initially thought because we rely on combine for several instructions and a change in a "base" pattern needs to propagate to all those. For the lack of a better idea I used a function call property to s

[PATCH 2/8] ifn: Add else-operand handling.

This patch adds else-operand handling to the internal functions. gcc/ChangeLog: * internal-fn.cc (add_mask_and_len_args): Rename... (add_mask_else_and_len_args): ...to this and add else handling. (expand_partial_load_optab_fn): Use adjusted function. (expand_partia

[PATCH 1/8] docs: Document maskload else operand and behavior.

This patch amends the documentation for masked loads (maskload, vec_mask_load_lanes, and mask_gather_load as well as their len counterparts) with an else operand. gcc/ChangeLog: * doc/md.texi: Document masked load else operand. --- gcc/doc/md.texi | 60 +++

Subject: [PATCH 0/8] Masked load else operand.

I figured it's easier to parse this as a series rather than one big patch, in particular since target-specific code is involved. This adds an else operand to masked-load operations in order to avoid implicit dependencies on zeroed masked-out elements. riscv does not mandate zeroing for those but

[PATCH] c++: Fix constrained auto deduction templ parms resolution [PR114915, PR115030]

When deducing auto for `adc_return_type`, `adc_variable_type`, and `adc_decomp_type` contexts (at the usage time), we try to resolve the outermost template arguments to be used for satisfaction. This is done by one of the following, depending on the scope: 1. Checking the `DECL_TEMPLATE_INFO` of t

Re: [PATCH] gm2: add missing debug output guard

On Sun, 11 Aug 2024, Wilken Gottwalt wrote: >> I noticed this has not been pushed yet and believe Wilken does not have >> write/push access - so just pushed this on his behalf. >> >> Wilken, it may be good to note this as part of patch submission. > Thank for pushing this. But now I'm a bit confu

Re: [PATCH] gm2: add missing debug output guard

Wilken Gottwalt writes: > On Sat, 10 Aug 2024 13:43:33 +0200 (CEST) > Gerald Pfeifer wrote: > >> On Tue, 23 Jul 2024, Gaius Mulley wrote: >> >> gcc/gm2: >> >> * gm2-libs-iso/MemStream.mod: Guard debug output. >> > many thanks! >> >> I noticed this has not been pushed yet and believe Wilken do

[PATCH, committed] Fortran: silence Wmaybe-uninitialized warnings for LTO build [PR116221]

Dear all, I've pushed the attached simple patch for initialization of local variables to silence warnings for LTO builds after Sam James' confirmation as https://gcc.gnu.org/g:2b23a444bcf7eb67cb04b431d8fd4fa6f65222de Thanks, Harald From 2b23a444bcf7eb67cb04b431d8fd4fa6f65222de Mon Sep 17 00:00:

Re: [PATCH v6] c++: Fix constrained auto deduction in templ spec scopes [PR114915]

Hi. Based on your comments here, and the discussions in another thread https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657703.html I have made another patch to resolve this issue (as well as another bug) that I will be sending right now. On Thu, 2024-07-18 at 22:16 -0400, Jason Merrill wrote

Re: [PATCH v5] Target-independent store forwarding avoidance.

On 8/9/24 8:58 AM, Manolis Tsamis wrote: This pass detects cases of expensive store forwarding and tries to avoid them by reordering the stores and using suitable bit insertion sequences. For example it can transform this: [ ... ] Trying to bootstrap (enabled by default) on 68k: ../../..

Re: [x86 PATCH] PR target/116275: Handle STV of *extenddi2_doubleword_highpart

On Sun, Aug 11, 2024 at 12:16 PM Roger Sayle wrote: > > > This patch resolves PR target/116275, a recent ICE-on-valid regression on > -m32 caused by my recent change to enable STV of DImode arithmeric right > shift on non-AVX512VL targets. The oversight is that the i386 backend > contains an *ext

[patch,avr,applied]: Use lra_in_progress resp. reload_in_progress depending on -mlra

This patch adds function avr.cc::ra_in_progress() that returns lra_in_progress resp. reload_in_progress depending on avr_lra_p. Currently, direct use of ra_in_progress() is only made with -mlog=. Johann -- AVR: Add function avr.cc::ra_in_progress(). It returns lra_in_progress resp. re

[avr,patch,applied] avr: Don't document -mlra

This patch sets the Undocumented flag for -mlra because it is likely just a transient option and only experimental. Johann -- AVR: -mlra is not documeted in TEXI. gcc/ * config/avr/avr.opt (mlra): Set Undocumented flag. diff --git a/gcc/config/avr/avr.opt b/gcc/config/avr/

[PATCH v2] RISC-V: Make sure high bits of usadd operands is clean for HI/QI [PR116278]

From: Pan Li For QI/HImode of .SAT_ADD, the operands may be sign-extended and the high bits of Xmode may be all 1 which is not expected. For example as below code. signed char b[1]; unsigned short c; signed char *d = b; int main() { b[0] = -40; c = ({ (unsigned short)d[0] < 0xFFF6 ? (unsig

[x86 PATCH] PR target/116275: Handle STV of *extenddi2_doubleword_highpart

This patch resolves PR target/116275, a recent ICE-on-valid regression on -m32 caused by my recent change to enable STV of DImode arithmeric right shift on non-AVX512VL targets. The oversight is that the i386 backend contains an *extenddi2_doubleword_highpart instruction (whose pattern is an arit