Re: [PATCH] rename make_eh_edges to make_eh_edge

On Oct 20, 2023, Richard Biener wrote: > OK. Thanks. >> * tree-eh.h (make_eh_edges): Rename to... >> (make_eh_edge): ... this. >> * tree-eh.cc: Likewise. Adjust all callers. Ugh, "Adjust all callers" is no longer enough, all files need to be mentioned explicitly. So I'm pushing it with:

Re: [PATCH v4] Introduce strub: machine-independent stack scrubbing

Ping? https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633675.html I'm combining the gcc/ipa-strub.cc bits from https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633526.html -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Wed, Oct 25, 2023 at 07:03:43PM +, Qing Zhao wrote: > For the code generation impact: > > turning the original x.buf > to a builtin function call > __builtin_with_access_and_size(x,buf, x.L,-1) > > might inhibit some optimizations from happening before the builtin is > evaluated into obj

[PATCH][_Hashtable] Use RAII to restore Rehash state

    libstdc++: [_Hashtable] Use RAII type to manage rehash functor state     Replace usage of __try/__catch with a RAII type to restore rehash functor     state when needed.     libstdc++-v3/ChangeLog:     * include/bits/hashtable_policy.h (_RehashStateGuard): New.     (_Inser

Re: PR111754

On Thu, 26 Oct 2023 at 04:09, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > On Wed, 25 Oct 2023 at 02:58, Richard Sandiford > > wrote: > >> > >> Hi, > >> > >> Sorry the slow review. I clearly didn't think this through properly > >> when doing the review of the original patch, so

Re: [PATCH] Ignore case of header line in dg-extract-results.py

On 10/25/23 22:09, Alexandre Oliva wrote: On Oct 24, 2023, Paul Iannetta wrote: * dg-extract-results.py: Make the test_run regex case insensitive. It looks reasonable to me, but I'm not sure this is a change I'm entitled to approve. Thanks! Even so, I trust your judgme

Re: [PATCH] Ignore case of header line in dg-extract-results.py

On Oct 24, 2023, Paul Iannetta wrote: > * dg-extract-results.py: Make the test_run regex case > insensitive. It looks reasonable to me, but I'm not sure this is a change I'm entitled to approve. Thanks! -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/

[PATCH] DOC: Update COND_LEN document

As Richard's suggested. We need to adapt doc for cond_len operations. gcc/ChangeLog: * doc/md.texi: Update document. --- gcc/doc/md.texi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi index daa318ee3da..dd2c26edf7b 100644 --- a/gcc/doc/md.texi ++

[PATCH] libgcov: Fix gcov overlap bugs of divide to 0

Fix the long lasting issue of `gcov-tool overlap xxx yyy`, divide to 0 caused the output shows a lot of nans, another problem is the counts in file are never acculated leads to incorrect results. Signed-off-by: Xionghu Luo libgcc/ChangeLog: * libgcov-util.c (compute_one_gcov): Avoid di

[PATCH v2] VECT: Remove the type size restriction of vectorizer

From: Pan Li Update in v2: * Fix one ICE of type assertion. * Adjust some test cases for aarch64 sve and riscv vector. Original log: The vectoriable_call has one restriction of the size of data type. Aka DF to DI is allowed but SF to DI isn't. You may see below message when try to vectorize fu

[RFC] RISC-V: Support -mcmodel=large.

This is a RFC patch for large code model implementation. gcc/ChangeLog: * gcc/config/riscv/predicates.md(move_operand): Check SYMBOL_REF and LABEL_REF type. (call_insn_operand): Support for CM_Large. (pcrel_symbol_operand): New. * gcc/config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Add builtin_d

Re: Re: [PATCH] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

I think it's QEMU issue: line 15: 1520161 Aborted                 (core dumped) QEMU_CPU="$(march-to-cpu-opt --get-riscv-tag $1)" qemu-riscv$xlen -r 5.10 "${qemu_args[@]}" -L ${RISC_V_SYSROOT} "$@" FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load_run-11.c execution test I use

[PATCH V2 2/2] Support vec_cmpmn/vcondmn for v2hf/v4hf.

>vcond and vcondeq shouldn't be necessary if there's >vcond_mask and vcmp support which is the "modern" >way of handling vcond. Unless the ISA really can do >compare and select with a single instruction. The V2 patch remove vcond/vcondu from the initial version[1], but there're many optimizations

[PATCH V2 1/2] Pass type of comparison operands instead of comparison result to truth_type_for in build_vec_cmp.

>I think it's indeed on purpose that the result of v1 < v2 is a signed >integer vector type. >But build_vec_cmp should not use the truth type for the result but instead the >truth type for the comparison, so Change build_vec_cmp in both c/c++, also notice for jit part, it already uses type of comp

Re: Re: [PATCH] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

FAIL: gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-5.c -O3 -ftree-vectorize --param riscv-autovec-lmul=dynamic  scan-assembler e32,m4 FAIL: gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-2.c -O3 -ftree-vectorize --param riscv-autovec-lmul=dynamic  scan-assembler e32,m8 These 2 FAILs are bogus. T

[PATCH] RISC-V: Pass abi to g++ rvv testsuite

On rv32gcv testcases like g++.target/riscv/rvv/base/bug-22.C fail with: FAIL: g++.target/riscv/rvv/base/bug-22.C (test for excess errors) Excess errors: cc1plus: error: ABI requires '-march=rv32' This patch adds the -mabi argument to g++ rvv tests. gcc/testsuite/ChangeLog: * g++.target/r

Re: [RFC] RISC-V: elide sign extend when expanding cmp_and_jump

On 10/24/23 22:01, Vineet Gupta wrote: RV64 comapre and branch instructions only support 64-bit operands. The backend unconditionally generates zero/sign extend at Expand time for compare and branch operands even if they are already as such e.g. function args which ABI guarantees to be sign-exten

Re: [PATCH] bpf: Improvements in CO-RE builtins implementation.

Hi David, Thanks for the comments. I have just realized that I introduced several errors in the patch by mistake right before I sent it. Like the missing "*". Apologies, I will revise it and send a new patch in a moment. Thanks, Cupertino David Faust writes: > On 10/25/23 11:51, Cupertino Mi

Re: [PATCH] bpf: Improvements in CO-RE builtins implementation.

On 10/25/23 11:51, Cupertino Miranda wrote: > Hi everyone, > > This patch contains some more recent improvements to BPF CO-RE builtins. > Please find further details of the changes on the patch header. > > Looking forward for your review and comments. > > Best regards, > Cupertino Miranda Hi

Re: PR111754

Prathamesh Kulkarni writes: > On Wed, 25 Oct 2023 at 02:58, Richard Sandiford > wrote: >> >> Hi, >> >> Sorry the slow review. I clearly didn't think this through properly >> when doing the review of the original patch, so I wanted to spend >> some time working on the code to get a better underst

Re: Re: [PATCH] internal-fn: Add VCOND_MASK_LEN.

Yeah. I think Robin may need this : TREE_CODE (else_val) == SSA_NAAME && SSA_NAME_IS_DEFAULT_DEF (else_val) && VAR_P (SSA_NAME_VAR (else_val)) to differentiate whether the ELSE VALUE is uninitialized SSA or not. juzhe.zh...@rivai.ai From: Richard Sandiford Date: 2023-10-26 06:32 To: 钟居哲 C

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Wed, Oct 25, 2023 at 10:27:41PM +, Qing Zhao wrote: > > > > On Oct 25, 2023, at 6:06 PM, Kees Cook wrote: > > > > On Wed, Oct 25, 2023 at 01:27:29PM +, Qing Zhao wrote: > >> A. Add an additional argument, the size parameter, to __bdos, > >> A.1, during FE; > >> A.2, during

Re: [PATCH] internal-fn: Add VCOND_MASK_LEN.

钟居哲 writes: >>> Which one is right? > Hi, Richard. Let me explain this situation. > > Both situations are possible. It's depending on the 'ELSE' value whether it > is unitialized value. > > For reduction case: > > for (int i = 0; i < n; i++) > result += a[i] > > The trailing elements should be

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 25, 2023, at 6:06 PM, Kees Cook wrote: > > On Wed, Oct 25, 2023 at 01:27:29PM +, Qing Zhao wrote: >> A. Add an additional argument, the size parameter, to __bdos, >> A.1, during FE; >> A.2, during gimplification phase; > > I just wanted to clarify that this is all just

[PATCH] internal-fn: Add VCOND_MASK_LEN.

>> Which one is right? Hi, Richard. Let me explain this situation. Both situations are possible. It's depending on the 'ELSE' value whether it is unitialized value. For reduction case: for (int i = 0; i < n; i++) result += a[i] The trailing elements should be well-defined, keep the original

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Wed, Oct 25, 2023 at 01:27:29PM +, Qing Zhao wrote: > A. Add an additional argument, the size parameter, to __bdos, > A.1, during FE; > A.2, during gimplification phase; I just wanted to clarify that this is all just an "internal" detail, yes? i.e. the __bdos() used by in C cod

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Tue, Oct 24, 2023 at 07:51:55PM -0400, Siddhesh Poyarekar wrote: > Yes, that's the tradeoff. However, maybe this is the point where Kees jumps > in and say the kernel doesn't really care as much or something like that :) "I only care about -O2" :) -- Kees Cook

Re: [PATCH] internal-fn: Add VCOND_MASK_LEN.

Robin Dapp writes: >> At first, this seemed like an odd place to fold away the length. >> AFAIK the length in res_op is inherited directly from the original >> operation, and so it isn't any more redundant after the fold than >> it was before. But I suppose the reason for doing it here is that >>

Re: [PATCH v2 3/4] build: Add libgrust as compilation modules

Hi! On 2023-10-25T13:06:48+0200, Arthur Cohen wrote: > From: Pierre-Emmanuel Patry > > Define the libgrust directory as a host compilation module as well as > for targets. I don't see a response to Richard's comments:

Re: [PATCH] c++/modules: fix up recent testcases

On 10/25/23 14:32, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk? Declaring get() inline seems necessary to avoid link failure: /usr/bin/ld: /tmp/ccwdv6Co.o: in function `g3@pr105322.Decltype()': decltype-1_b.C:(.text._ZW8pr105322W8Decltype2g3v[_ZW8pr105

Re: [PATCH] c++/modules: fix up recent testcases

Patrick, thanks for noticing this, and this is a suitable workaround for another bug. We should either be emitting the definition of that member function in the object file of its containing function. Or it should be implicitly inline. I know in module perview the in-class defined member fun

Ping: [PATCH 6/6] PowerPC: Add support for 1,024 bit DMR registers.

Ping patch. | Date: Wed, 18 Oct 2023 20:06:20 -0400 | From: Michael Meissner | Subject: [PATCH 6/6] PowerPC: Add support for 1,024 bit DMR registers. | Message-ID: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633516.html -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA,

Ping: [PATCH 5/6] PowerPC: Switch to dense math names for all MMA operations.

Ping patch. | Date: Wed, 18 Oct 2023 20:04:44 -0400 | From: Michael Meissner | Subject: [PATCH 5/6] PowerPC: Switch to dense math names for all MMA operations. | Message-ID: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633515.html -- Michael Meissner, IBM PO Box 98, Ayer, Massachus

Ping: [PATCH 4/6] PowerPC: Make MMA insns support DMR registers.

Ping patch. | Date: Wed, 18 Oct 2023 20:03:02 -0400 | From: Michael Meissner | Subject: [PATCH 4/6] PowerPC: Make MMA insns support DMR registers. | Message-ID: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633514.html -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 014

Ping: [PATCH 3/6] PowerPC: Add support for accumulators in DMR registers.

Ping patch: | ate: Wed, 18 Oct 2023 20:01:54 -0400 | From: Michael Meissner | Subject: [PATCH 3/6] PowerPC: Add support for accumulators in DMR registers. | Message-ID: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633513.html -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts,

Ping: [PATCH 2/6] PowerPC: Make -mcpu=future enable -mblock-ops-vector-pair.

Ping patch. | Date: Wed, 18 Oct 2023 20:00:18 -0400 | From: Michael Meissner | Subject: [PATCH 2/6] PowerPC: Make -mcpu=future enable -mblock-ops-vector-pair. | Message-ID: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633512.html -- Michael Meissner, IBM PO Box 98, Ayer, Massachuse

Re: [NVPTX] Patch pings...

Hi Roger! Thanks for your patience! I very much know how it's frustrating... I promise I'll get to your patches: in fact I already started looking into these before the Cauldron, but ran into GCC/nvptx things that I didn't understand but felt I need to understand/address first, then after the Cau

Ping: [PATCH 1/6] PowerPC: Add -mcpu=future option

Ping patch. | Date: Wed, 18 Oct 2023 19:58:56 -0400 | From: Michael Meissner | Subject: Re: [PATCH 1/6] PowerPC: Add -mcpu=future option | Message-ID: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633511.html -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email:

Ping: [PATCH] Power10: Add options to disable load and store vector pair.

Ping patch: | Date: Fri, 13 Oct 2023 19:41:13 -0400 | From: Michael Meissner | Subject: [PATCH] Power10: Add options to disable load and store vector pair. | Message-ID: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632987.html -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts,

Re: [PATCH] internal-fn: Add VCOND_MASK_LEN.

> At first, this seemed like an odd place to fold away the length. > AFAIK the length in res_op is inherited directly from the original > operation, and so it isn't any more redundant after the fold than > it was before. But I suppose the reason for doing it here is that > we deliberately create I

Re: [PATCH] c++: another build_new_1 folding fix [PR111929]

On 10/25/23 12:03, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- We also need to avoid folding 'outer_nelts_check' when in a template context to prevent an ICE on the below testcase. This patch achieves this by replacing the fold_

[pushed] tree: update address_space comment

Pushing as obvious. -- 8< -- Mention front-end uses of the address_space bit-field, and remove the inaccurate "only". gcc/ChangeLog: * tree-core.h (struct tree_base): Update address_space comment. --- gcc/tree-core.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --gi

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 25, 2023, at 11:38 AM, Richard Biener > wrote: > > > >> Am 25.10.2023 um 16:50 schrieb Siddhesh Poyarekar : >> >> On 2023-10-25 09:27, Qing Zhao wrote: > On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar > wrote: On 2023-10-24 18:51, Qing Zhao wrote: > Thank

[PATCH] c++: more ahead-of-time -Wparentheses warnings

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Now that we don't have to worry about looking thruogh NON_DEPENDENT_EXPR, we can easily extend the -Wparentheses warning in convert_for_assignment to consider (non-dependent) templated assignment operator exp

[PATCH] bpf: Improvements in CO-RE builtins implementation.

Hi everyone, This patch contains some more recent improvements to BPF CO-RE builtins. Please find further details of the changes on the patch header. Looking forward for your review and comments. Best regards, Cupertino Miranda commit 6054209c0a8af9c3e6363550bf2ba4f4f2172eba Author: Cupertino

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 25, 2023, at 10:50 AM, Siddhesh Poyarekar wrote: > > On 2023-10-25 09:27, Qing Zhao wrote: >>> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote: >>> >>> On 2023-10-24 18:51, Qing Zhao wrote: Thanks for the proposal! So what you suggested is: For every x.buf, chan

[PATCH] c++/modules: fix up recent testcases

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? Declaring get() inline seems necessary to avoid link failure: /usr/bin/ld: /tmp/ccwdv6Co.o: in function `g3@pr105322.Decltype()': decltype-1_b.C:(.text._ZW8pr105322W8Decltype2g3v[_ZW8pr105322W8Decltype2g3v]+0x18): undefined referen

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 25, 2023, at 7:13 AM, Richard Biener > wrote: > > > >> Am 25.10.2023 um 12:47 schrieb Martin Uecker : >> >> Am Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh Poyarekar: On 2023-10-25 04:16, Martin Uecker wrote: Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Am Mittwoch, dem 25.10.2023 um 13:13 +0200 schrieb Richard Biener: > > > Am 25.10.2023 um 12:47 schrieb Martin Uecker : > > > > Am Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh Poyarekar: > > > > On 2023-10-25 04:16, Martin Uecker wrote: > > > > Am Mittwoch, dem 25.10.2023 um 08:43 +0

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 25, 2023, at 6:39 AM, Martin Uecker wrote: > > Am Mittwoch, dem 25.10.2023 um 12:25 +0200 schrieb Richard Biener: >> >>> Am 25.10.2023 um 10:16 schrieb Martin Uecker : >>> >>> Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener: >> Am 24.10.2023 um 22:38 schr

Re: [PATCH] testsuite: Fix _BitInt in gcc.misc-tests/godump-1.c

On Tue, Oct 24, 2023, 11:03 AM Jeff Law wrote: > > > On 10/24/23 09:26, Stefan Schulze Frielinghaus wrote: > > Currently _BitInt is only supported on x86_64 which means that for other > > targets all tests fail with e.g. > > > > gcc.misc-tests/godump-1.c:237:1: sorry, unimplemented: '_BitInt(32)'

Re: [RFC] RISC-V: elide sign extend when expanding cmp_and_jump

On 10/25/23 06:52, Jeff Law wrote: On 10/25/23 07:47, Robin Dapp wrote: Well, it doesn't seem like there's a lot of difference between doing it in the generic expander bits vs target expander bits -- the former just calls into the latter for the most part.  Thus if the subreg-promoted stat

Re: [RFC] RISC-V: elide sign extend when expanding cmp_and_jump

On 10/25/23 09:30, Jeff Law wrote:   - Should some common-code part be more suited to handle that?     We already elide redundant sign-zero extensions for other     reasons.  Maybe we could add subreg promoted handling there? Not in the context of this specific issue. Robin's point (IIUC) is

Re: [RFC] RISC-V: elide sign extend when expanding cmp_and_jump

On 10/25/23 10:25, Vineet Gupta wrote: Hey Robin, On 10/25/23 00:12, Robin Dapp wrote: Hi Vineet, I was thinking of two things while skimming the code:   - Couldn't we do this in the expanders directly?  Or is the     subreg-promoted info gone until we reach that? Following is the call s

Re: [PATCH v2] PR 91865: Avoid ZERO_EXTEND of ZERO_EXTEND in make_compound_operation.

On 10/25/23 03:21, Roger Sayle wrote: Hi Jeff, Many thanks for the review/approval of my fix for PR rtl-optimization/91865. Based on your and Richard Biener's feedback, I’d like to propose a revision calling simplify_unary_operation instead of simplify_const_unary_operation (i.e. Richi's reco

Re: [RFC] RISC-V: elide sign extend when expanding cmp_and_jump

Hey Robin, On 10/25/23 00:12, Robin Dapp wrote: Hi Vineet, I was thinking of two things while skimming the code: - Couldn't we do this in the expanders directly? Or is the subreg-promoted info gone until we reach that? Following is the call stack involved:   expand_gimple_cond     do

Re: [PING^2] More '#ifdef ASM_OUTPUT_DEF' -> 'if (TARGET_SUPPORTS_ALIASES)' etc.

On 10/25/23 02:38, Thomas Schwinge wrote: Hi! Ping. Grüße Thomas On 2023-09-19T10:47:56+0200, I wrote: Hi! Ping. Grüße Thomas On 2023-09-08T14:02:50+0200, I wrote: Hi! On 2017-08-10T15:42:13+0200, Jan Hubicka wrote: On 07/31/2017 11:57 AM, Yuri Gribov wrote: On Mon, Jul 31,

[PATCH] c++: another build_new_1 folding fix [PR111929]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- We also need to avoid folding 'outer_nelts_check' when in a template context to prevent an ICE on the below testcase. This patch achieves this by replacing the fold_build2 call with build2 (cp_fully_fold wil

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> Am 25.10.2023 um 16:50 schrieb Siddhesh Poyarekar : > > On 2023-10-25 09:27, Qing Zhao wrote: On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote: >>> >>> On 2023-10-24 18:51, Qing Zhao wrote: Thanks for the proposal! So what you suggested is: For every x.buf,

Re: [PATCH] s390: fix htm-builtins test cases

On 10/25/23 16:50, Juergen Christ wrote: > Transactional and non-transactional stores to the same cache line cause > transactions to abort on newer generations. Add sufficient padding to make > sure another cache line is used. > > Tested on s390. > > gcc/testsuite/ChangeLog: > > * gcc.tar

[PATCH] s390: fix htm-builtins test cases

Transactional and non-transactional stores to the same cache line cause transactions to abort on newer generations. Add sufficient padding to make sure another cache line is used. Tested on s390. gcc/testsuite/ChangeLog: * gcc.target/s390/htm-builtins-1.c: Fix. * gcc.target/s390

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On 2023-10-25 09:27, Qing Zhao wrote: On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote: On 2023-10-24 18:51, Qing Zhao wrote: Thanks for the proposal! So what you suggested is: For every x.buf, change it as a __builtin_with_size(x.buf, x.L) in the FE, then the call to the _bdos (x.bu

RE: [x86 PATCH] PR target/110511: Fix reg allocation for widening multiplications.

Hi Uros, I've tried your suggestions to see what would happen. Alas, allowing both operands to (i386's) widening multiplications to be nonimmediate_operand results in 90 additional testsuite unexpected failures", and 41 unresolved testcase, around things like: gcc.c-torture/compile/di.c:6:1: err

[committed] i386: Narrow test instructions with immediate operands [PR111698]

i386: Narrow test instructions with immediate operands [PR111698] Narrow test instructions with immediate operand that test memory location for zero. E.g. testl $0x00aa, mem can be converted to testb $0xaa, mem+2. Reject targets where reading (possibly unaligned) part of memory location after

Re: [PATCH] c++: build_new_1 and non-dep array size [PR111929]

On Tue, 24 Oct 2023, Jason Merrill wrote: > On 10/24/23 13:03, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > like the right approach? > > > > -- >8 -- > > > > This PR is another instance of NON_DEPENDENT_EXPR having acted as an > > "analysis barri

[COMMITTED] Faster irange union for appending ranges.

Its a common idiom to build a range by unioning other ranges into another one.  If this is done sequentially, those new ranges can be simply appended to the end of the existing range, avoiding some expensive processing fro the general case. This patch identifies and optimizes this situation. 

[NVPTX] Patch pings...

Random fact: there have been no changes to nvptx.md in 2023 apart from Jakub's tree-wide update to the copyright years in early January. Please can I ping two of my of pending Nvidia nvptx patches: "Correct pattern for popcountdi2 insn in nvptx.md" from January https://gcc.gnu.org/pipermail/gcc

Re: [RFC] RISC-V: elide sign extend when expanding cmp_and_jump

On 10/25/23 07:47, Robin Dapp wrote: Well, it doesn't seem like there's a lot of difference between doing it in the generic expander bits vs target expander bits -- the former just calls into the latter for the most part. Thus if the subreg-promoted state is available in the target expander

Re: [RFC] RISC-V: elide sign extend when expanding cmp_and_jump

> Well, it doesn't seem like there's a lot of difference between doing > it in the generic expander bits vs target expander bits -- the former > just calls into the latter for the most part. Thus if the > subreg-promoted state is available in the target expander, I'd expect > it to be available

Re: [RFC] RISC-V: elide sign extend when expanding cmp_and_jump

On 10/25/23 01:12, Robin Dapp wrote: Hi Vineet, I was thinking of two things while skimming the code: - Couldn't we do this in the expanders directly? Or is the subreg-promoted info gone until we reach that? Well, it doesn't seem like there's a lot of difference between doing it in t

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote: > > On 2023-10-24 18:51, Qing Zhao wrote: >> Thanks for the proposal! >> So what you suggested is: >> For every x.buf, change it as a __builtin_with_size(x.buf, x.L) in the FE, >> then the call to the _bdos (x.buf, 1) will >> Become: >>

Re: [pushed][PATCH v1] LoongArch: Fix vfrint-releated comments in lsxintrin.h and lasxintrin.h

Pushed to r14-4926. 在 2023/10/23 上午10:13, Chenghui Pan 写道: The comment of vfrint-related intrinsic functions does not match the return value type in definition. This patch fixes these comments. gcc/ChangeLog: * config/loongarch/lasxintrin.h (__lasx_xvftintrnel_l_s): Fix comments.

Re: [pushed][PATCH v1] LoongArch: Implement __builtin_thread_pointer for TLS.

Pushed to r14-4925. 在 2023/10/24 下午2:40, chenxiaolong 写道: gcc/ChangeLog: * config/loongarch/loongarch.md (get_thread_pointer):Adds the instruction template corresponding to the __builtin_thread_pointer function. * doc/extend.texi:Add the __builtin_thread_pointe

[pushed] c++: add fixed testcase [PR99804]

Tested on x86_64-pc-linux-gnu, pushed to trunk. -- >8 -- We accept the non-dependent call f(e) here ever since the NON_DEPENDENT_EXPR removal patch r14-4793-gdad311874ac3b3. I haven't looked closely into why but I suspect wrapping 'e' in a NON_DEPENDENT_EXPR was causing the argument conversion to

Re: [PATCH] gcc/jit/jit-recording.cc: recording::global::write_to_dump: Avoid crashes when writing psuedo-C for globals with string initializers.

On Fri, 2022-11-25 at 02:13 +0530, Vibhav Pant via Jit wrote: > If a char * global was initialized with a rvalue from > `gcc_jit_context_new_string_literal` containing a format string, > dumping the context causes libgccjit to SIGSEGV due to an improperly > constructed call to vasprintf. The follow

[PATCH V2] RISC-V: Add AVL propagation PASS for RVV auto-vectorization

This patch addresses the redundant AVL/VL toggling in RVV partial auto-vectorization which is a known issue for a long time and I finally find the time to address it. Consider a simple vector addition operation: https://godbolt.org/z/7hfGfEjW3 void foo (int *__restrict a, int *__restrict

Re: [PATCH V14 4/4] ree: Improve ree pass using defined abi interfaces

On 24/10/23 11:47 pm, Vineet Gupta wrote: > > > On 10/24/23 10:03, Ajit Agarwal wrote: >> Hello Vineet, Jeff and Bernhard: >> >> This version 14 of the patch uses abi interfaces to remove zero and sign >> extension elimination. >> This fixes aarch64 regressions failures with aggressive CSE. >

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> Am 25.10.2023 um 12:47 schrieb Martin Uecker : > > Am Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh Poyarekar: >>> On 2023-10-25 04:16, Martin Uecker wrote: >>> Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener: > Am 24.10.2023 um 22:38 schrieb Martin Uec

Re: [PATCH v9 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces

On 25/10/23 2:06 am, rep.dot@gmail.com wrote: > On 24 October 2023 09:36:22 CEST, Ajit Agarwal wrote: >> Hello Bernhard: >> >> On 23/10/23 7:40 pm, Bernhard Reutner-Fischer wrote: >>> On Mon, 23 Oct 2023 12:16:18 +0530 >>> Ajit Agarwal wrote: >>> Hello All: Addressed below r

Re: [PATCH v9 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces

On 25/10/23 2:19 am, Vineet Gupta wrote: > On 10/24/23 13:36, rep.dot@gmail.com wrote: >> As said, I don't see why the below was not cleaned up before the V1 >> submission. >> Iff it breaks when manually CSEing, I'm curious why? The function below looks identical in v12 of

[PATCH v2 4/4] build: Regenerate build files

From: Pierre-Emmanuel Patry Regenerate all build files. ChangeLog: * Makefile.in: * configure: Regenerate. libgrust/ChangeLog: * Makefile.in: New file. * aclocal.m4: New file. * configure: New file. * libproc_macro/Makefile.in: New file. libgm2

[PATCH v2 3/4] build: Add libgrust as compilation modules

From: Pierre-Emmanuel Patry Define the libgrust directory as a host compilation module as well as for targets. ChangeLog: * Makefile.def: Add libgrust as host & target module. * configure.ac: Add libgrust to host tools list. gcc/rust/ChangeLog: * config-lang.in: Add li

[PATCH v2 2/4] libgrust: Add libproc_macro and build system

From: Pierre-Emmanuel Patry Add some dummy files in libproc_macro along with its build system. libgrust/Changelog: * Makefile.am: New file. * configure.ac: New file. * libproc_macro/Makefile.am: New file. * libproc_macro/proc_macro.cc: New file. * libproc

[PATCH v2 1/4] libgrust: Add entry for maintainers and stub changelog file.

ChangeLog: * MAINTAINERS: Add maintainers for libgrust. contrib/ChangeLog: * gcc-changelog/git_commit.py: Add libgrust. * gcc_update: Add libgrust file dependencies Co-authored-by: Pierre-Emmanuel Patry --- MAINTAINERS | 1 + contrib/gcc-changel

Re: PR111754

On Wed, 25 Oct 2023 at 02:58, Richard Sandiford wrote: > > Hi, > > Sorry the slow review. I clearly didn't think this through properly > when doing the review of the original patch, so I wanted to spend > some time working on the code to get a better understanding of > the problem. > > Prathamesh

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Am Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh Poyarekar: > On 2023-10-25 04:16, Martin Uecker wrote: > > Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener: > > > > > > > Am 24.10.2023 um 22:38 schrieb Martin Uecker : > > > > > > > > Am Dienstag, dem 24.10.2023 um 20

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Am Mittwoch, dem 25.10.2023 um 12:25 +0200 schrieb Richard Biener: > > > Am 25.10.2023 um 10:16 schrieb Martin Uecker : > > > > Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener: > > > > > > > > Am 24.10.2023 um 22:38 schrieb Martin Uecker : > > > > > > > > Am Dienstag, dem 24

[committed] libstdc++: Build libstdc++_libbacktrace.a as PIC [PR111936]

Tested x86_64-linux. Pushed to trunk, will backport to 12 and 13. -- >8 -- In order for std::stacktrace to be used in a shared library, the libbacktrace symbols need to be built with -fPIC. Add the libtool -prefer-pic flag to the commands in src/libbacktrace/Makefile so that the archive contains

Re: [PATCH v4] c-family: Implement __has_feature and __has_extension [PR60512]

On 11/10/2023 14:31, Alex Coplan wrote: > On 27/09/2023 15:27, Alex Coplan wrote: > > Hi, > > > > This is a v4 patch to address Jason's feedback here: > > https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630911.html > > > > w.r.t. v3 it just removes a comment now that some uncertainty aro

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> Am 25.10.2023 um 10:16 schrieb Martin Uecker : > > Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener: >> Am 24.10.2023 um 22:38 schrieb Martin Uecker : >>> >>> Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao: Hi, Sid, Really appreciate for

Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On 2023-10-25 04:16, Martin Uecker wrote: Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener: Am 24.10.2023 um 22:38 schrieb Martin Uecker : Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao: Hi, Sid, Really appreciate for your example and detailed explanation. Ve

Re: [RFC 1/2] RISC-V: Add support for _Bfloat16.

> >>> +;; The conversion of DF to BF needs to be done with SF if there is a > >>> +;; chance to generate at least one instruction, otherwise just using > >>> +;; libfunc __truncdfbf2. > >>> +(define_expand "truncdfbf2" > >>> + [(set (match_operand:BF 0 "register_operand" "=f") > >>> + (f

Re: [PATCH v2] AArch64: Improve immediate generation

On 24/10/2023 18:27, Wilco Dijkstra wrote: v2: Use check-function-bodies in tests Further improve immediate generation by adding support for 2-instruction MOV/EOR bitmask immediates. This reduces the number of 3/4-instruction immediates in SPECCPU2017 by ~2%. Passes regress, OK for commit?

Minor fixes for OpenACC/Fortran 'self' clause for compute constructs (was: [PATCH, OpenACC 2.7] Implement self clause for compute constructs)

Hi! On 2023-10-25T10:57:06+0200, I wrote: > With minor textual conflicts resolved, I've pushed this to master branch > in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a > "OpenACC 2.7: Implement self clause for compute constructs", see > attached. > > > I'll then apply/submit a number of follow-o

Re: [PATCH 3/3]rs6000: split complicate constant to constant pool

Hi, "Kewen.Lin" writes: > on 2023/10/25 16:14, Jiufu Guo wrote: >> >> Hi, >> >> "Kewen.Lin" writes: >> >>> Hi, >>> >>> on 2023/10/25 10:00, Jiufu Guo wrote: Hi, Sometimes, a complicated constant is built via 3(or more) instructions to build. Generally speaking, it would

Handle OpenACC 'self' clause for compute constructs in OpenACC 'kernels' decomposition (was: Extend test suite coverage for OpenACC 'self' clause for compute constructs (was: [PATCH, OpenACC 2.7] Impl

Hi! On 2023-10-25T11:29:52+0200, I wrote: > On 2023-10-25T10:57:06+0200, I wrote: >> With minor textual conflicts resolved, I've pushed this to master branch >> in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a >> "OpenACC 2.7: Implement self clause for compute constructs", see >> attached. >> >>

Extend test suite coverage for OpenACC 'self' clause for compute constructs (was: [PATCH, OpenACC 2.7] Implement self clause for compute constructs)

Hi! On 2023-10-25T10:57:06+0200, I wrote: > With minor textual conflicts resolved, I've pushed this to master branch > in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a > "OpenACC 2.7: Implement self clause for compute constructs", see > attached. > > > I'll then apply/submit a number of follow-o

[PATCH] s390: Fix constraint for insn *cmphi_ccu

Currently for an unsigned 16-bit comparison between memory and an immediate where the high bit is set, a clc is emitted. This is because the constant is created for mode HI and therefore sign extended. This means constraint D does not hold anymore. Since the mode already restricts the immediate

[PATCH v2] PR 91865: Avoid ZERO_EXTEND of ZERO_EXTEND in make_compound_operation.

Hi Jeff, Many thanks for the review/approval of my fix for PR rtl-optimization/91865. Based on your and Richard Biener's feedback, I’d like to propose a revision calling simplify_unary_operation instead of simplify_const_unary_operation (i.e. Richi's recommendation). I was originally concerned th

Consistently order 'OMP_CLAUSE_SELF' right after 'OMP_CLAUSE_IF' (was: [PATCH, OpenACC 2.7] Implement self clause for compute constructs)

Hi! On 2023-10-25T10:57:06+0200, I wrote: > With minor textual conflicts resolved, I've pushed this to master branch > in commit 3a3596389c2e539cb8fd5dc5784a4e2afe193a2a > "OpenACC 2.7: Implement self clause for compute constructs", see > attached. > > > I'll then apply/submit a number of follow-o

  1   2   >