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

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? - Should some common-code part be more suited to handle that? We already elide redundant sign-zero extensions for ot

Re: [PATCH 1/3]rs6000: update num_insns_constant for 2 insns

Hi, "Kewen.Lin" writes: > Hi, > > on 2023/10/25 10:00, Jiufu Guo wrote: >> Hi, >> >> Trunk gcc supports more constants to be built via two instructions: e.g. >> "li/lis; xori/xoris/rldicl/rldicr/rldic". >> And then num_insns_constant should also be updated. >> > > Thanks for updating this. >

Re: [PATCH 2/3]rs6000: using 'pli' to load 34bit-constant

Hi, "Kewen.Lin" writes: > on 2023/10/25 10:00, Jiufu Guo wrote: >> Hi, >> >> For constants with 16bit values, 'li or lis' can be used to generate >> the value. For 34bit constant, 'pli' is ok to generate the value. >> >> Bootstrap®test pass on ppc64{,le}. >> Is this ok for trunk? >> >> BR,

[PATCH v3 1/1] gcc: config: microblaze: fix cpu version check

The MICROBLAZE_VERSION_COMPARE was incorrectly using strcasecmp instead of strverscmp to check the mcpu version against feature options. By simply changing the define to use strverscmp, the new version 10.0 is treated correctly as a higher version than previous versions. Signed-off-by: Neal Frage

RE: [PATCH v1 1/1] gcc: config: microblaze: fix cpu version check

There is a microblaze cpu version 10.0 included in versal. If the minor version is only a single digit, then the version comparison will fail as version 10.0 will appear as 100 compared to version 6.00 or 8.30 which will calculate to values 600 and 830. The issue can be s

[PATCH] RISC-V: Fix multiple EXCESS test FAILs in RVV testsuite

gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/slp-mask-run-1.c: Fix test. * gcc.target/riscv/rvv/autovec/vls-vlmax/vec_extract-run.c: Ditto. * gcc.target/riscv/rvv/autovec/vls-vlmax/vec_extract-runu.c: Ditto. * gcc.target/riscv/rvv/autovec/vls-vlmax/vec_se

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

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 not be >> as faster as loading it from the constant pool (as a few >> discussions in PR63281).

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 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. Very helpful. > >

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

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 not be >>> as faster as loading it from th

[PING] libffi: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951] (was: [PATCH v5 GCC] libffi/test: Fix compilation for build s

Hi! Ping. Grüße Thomas On 2023-09-12T12:58:27+0200, I wrote: > Hi! > > On 2020-04-20T14:18:40+0100, "Maciej W. Rozycki via Gcc-patches" > wrote: >> Fix a problem with the libffi testsuite using a method to determine the >> compiler to use resulting in the tool being different from one the >

Re: [PATCH-1v4, expand] Enable vector mode for compare_by_pieces [PR111449]

Hi Haochen, The regression cases are caused by "targetm.scalar_mode_supported_p" I added for scalar mode checking. XImode, OImode and TImode (with -m32) are not enabled in ix86_scalar_mode_supported_p. So they're excluded from by pieces operations on i386. The original code doesn't do a check

[PING] libatomic: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951] (was: [PATCH v4 1/5] libatomic/test: Fix compilation for b

Hi! Ping. Grüße Thomas On 2023-09-12T13:03:28+0200, I wrote: > Hi! > > On 2020-04-04T00:00:44+0100, "Maciej W. Rozycki via Gcc-patches" > wrote: >> Fix a problem with the libatomic testsuite using a method to determine >> the compiler to use resulting in the tool being different from one th

Re: [PATCH] RISC-V: Fix multiple EXCESS test FAILs in RVV testsuite

Hi Juzhe, I guess that's OK but what's the problem here? Are the default options wrong so we need to overwrite them instead of adding some? Regards Robin

[PATCH] RISC-V: Change MD attribute avl_type into avl_type_idx[NFC]

Address kito's comments of AVL propagation patch. Change avl_type into avl_type_idx. No functionality change. gcc/ChangeLog: * config/riscv/riscv-protos.h (vlmax_avl_type_p): New function. * config/riscv/riscv-v.cc (vlmax_avl_type_p): Ditto. * config/riscv/riscv-vsetvl.c

Re: [PATCH] RISC-V: Change MD attribute avl_type into avl_type_idx[NFC]

LGTM. Regards Robin

[PING^2] More '#ifdef ASM_OUTPUT_DEF' -> 'if (TARGET_SUPPORTS_ALIASES)' etc. (was: [PATCH][v2] Introduce TARGET_SUPPORTS_ALIASES)

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, 2017 at 9:04 AM,

Re: Re: [PATCH] RISC-V: Fix multiple EXCESS test FAILs in RVV testsuite

In rvv.exp: we specify -march=rv64gcv_zfh However, when I built the toolchain with -march=rv64gcv_zfh_zvfh. Then link fail. All other tests like compress_run-1.c are works fine with : /* { dg-options "-O3 --param riscv-autovec-preference=fixed-vlmax -Wno-psabi" } */ So I adapt these tests lik

Re: Re: [PATCH] RISC-V: Fix multiple EXCESS test FAILs in RVV testsuite

FAIL: gcc.target/riscv/rvv/autovec/slp-mask-run-1.c -O3 -ftree-vectorize (test for excess errors) FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/pr110985.c -std=c99 -O3 -ftree-vectorize --param riscv-autovec-preference=fixed-vlmax check-function-bodies foo1 FAIL: gcc.target/riscv/rvv/autovec/vls-

Re: [PATCH-1v4, expand] Enable vector mode for compare_by_pieces [PR111449]

HAO CHEN GUI writes: > Hi Haochen, > The regression cases are caused by "targetm.scalar_mode_supported_p" I added > for scalar mode checking. XImode, OImode and TImode (with -m32) are not > enabled in ix86_scalar_mode_supported_p. So they're excluded from by pieces > operations on i386. > > Th

Re: PR111754

Sigh, I knew I should have waited until the morning to proof-read and send this. Richard Sandiford writes: > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc > index 40767736389..00fce4945a7 100644 > --- a/gcc/fold-const.cc > +++ b/gcc/fold-const.cc > @@ -10743,27 +10743,37 @@ fold_vec_perm_cst

Re: [PATCH] RISC-V: Fix multiple EXCESS test FAILs in RVV testsuite

> However, when I built the toolchain with -march=rv64gcv_zfh_zvfh. > Then link fail. Hmm, is it about zvfh or why does linking fail? Regards Robin

Re: Re: [PATCH] RISC-V: Fix multiple EXCESS test FAILs in RVV testsuite

Hmmm. I am not familiar with Binutils... I just adapted tests like others in the testsuite make them consistent. And turns out it can fix the issues... juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-10-25 16:44 To: juzhe.zh...@rivai.ai; gcc-patches CC: rdapp.gcc; kito.cheng; Kito.cheng; jef

RE: [PATCH-1v4, expand] Enable vector mode for compare_by_pieces [PR111449]

> -Original Message- > From: Richard Sandiford > Sent: Wednesday, October 25, 2023 4:40 PM > To: HAO CHEN GUI > Cc: Jiang, Haochen ; gcc-patches patc...@gcc.gnu.org> > Subject: Re: [PATCH-1v4, expand] Enable vector mode for compare_by_pieces > [PR111449] > > HAO CHEN GUI writes: > > Hi

Re: [PATCH, OpenACC 2.7] Implement self clause for compute constructs

Hi! On 2023-06-13T23:52:25+0800, Chung-Lin Tang via Gcc-patches wrote: > This patch implements the compiler side for the 'self' clause for compute > constructs: > parallel, kernels, and serial. > > As you know, the actual "local device" device type for libgomp is not yet > implemented, > so th

Enable 'c-c++-common/goacc/{if,self}-clause-1.c' for C++ (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] RISC-V: Export some functions from riscv-vsetvl to riscv-v

Address kito's comments of AVL propagation patch. Export the functions that are not only used by VSETVL PASS but also AVL propagation PASS. No functionality change. gcc/ChangeLog: * config/riscv/riscv-protos.h (has_vl_op): Export from riscv-vsetvl to riscv-v (tail_agnostic_p):

Re: [PATCH] RISC-V: Export some functions from riscv-vsetvl to riscv-v

LGTM, but plz mention it's NFC in the title, no v2 needed :) On Wed, Oct 25, 2023 at 5:03 PM Juzhe-Zhong wrote: > > Address kito's comments of AVL propagation patch. > > Export the functions that are not only used by VSETVL PASS but also AVL > propagation PASS. > > No functionality change. > gcc

Re: [PATCH] RISC-V: Change MD attribute avl_type into avl_type_idx[NFC]

Committed. juzhe.zh...@rivai.ai From: Juzhe-Zhong Date: 2023-10-25 16:35 To: gcc-patches CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong Subject: [PATCH] RISC-V: Change MD attribute avl_type into avl_type_idx[NFC] Address kito's comments of AVL propagation patch. Change avl_t

Re: Re: [PATCH] RISC-V: Export some functions from riscv-vsetvl to riscv-v

Thanks. Committed with NFC mentioned. juzhe.zh...@rivai.ai From: Kito Cheng Date: 2023-10-25 17:06 To: Juzhe-Zhong CC: gcc-patches; kito.cheng; jeffreyalaw; rdapp.gcc Subject: Re: [PATCH] RISC-V: Export some functions from riscv-vsetvl to riscv-v LGTM, but plz mention it's NFC in the title, no

Re: [PATCH] config, aarch64: Use a more compatible sed invocation.

On 24/10/2023 16:53, Iain Sandoe wrote: Although this came up initially when working on the Darwin Arm64 port, it also breaks cross-compilers on platforms with non-GNU sed. Tested on x86_64-darwin X aarch64-linux-gnu, aarch64-darwin, aarch64-linux-gnu and x86_64-linux-gnu. OK for master? tha

Disentangle handling of OpenACC 'host', 'self' pragma tokens (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] RISC-V: Fix multiple EXCESS test FAILs in RVV testsuite

> Hmmm. I am not familiar with Binutils... > > I just adapted tests like others in the testsuite make them consistent. > And turns out it can fix the issues.. I see where you're coming from, but can you assemble/link any executable with -march=..._zvfh? Probably not? Doesn't half of GCC's tests

Re: Re: [PATCH] RISC-V: Fix multiple EXCESS test FAILs in RVV testsuite

>> Doesn't half of >> GCC's testsuite fail then? No. Only a few tests failed (The tests are mentioned in this patch). All other tests passed no matter how I configure toolchain building. >> I can do that at some point if you don't want it >> but right now I'm on other things. No worry, I won't c

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

[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

[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

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

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. >> >>

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

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 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?

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: 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: 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: [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

[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: 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

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: 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

[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

[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 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 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

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

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: 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 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. >

[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] 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

[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: [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

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: 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: [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: [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 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

[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

[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. 

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] 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: [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

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

[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: [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

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,

[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: [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,

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: [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

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: [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 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: [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: 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: 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 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

[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 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] 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

[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

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

[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: [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_

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

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,

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:

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 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

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 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

  1   2   >