Re: [PATCH 2/3] LoongArch: Fix instruction costs [PR112936]

在 2023/12/14 上午9:16, chenglulu 写道: 在 2023/12/13 下午9:20, Xi Ruoyao 写道: On Wed, 2023-12-13 at 20:22 +0800, chenglulu wrote: 在 2023/12/10 上午1:03, Xi Ruoyao 写道: Replace the instruction costs in loongarch_rtx_cost_data constructor based on micro-benchmark results on LA464 and LA664. This allows

Re: [PATCH] match.pd: Optimize sign-extension followed by truncation [PR113024]

On Thu, 14 Dec 2023, Jakub Jelinek wrote: > Hi! > > While looking at a bitint ICE, I've noticed we don't optimize > in f1 and f5 functions below the 2 casts into just one at GIMPLE, > even when optimize it in convert_to_integer if it appears in the same > stmt. The large match.pd simplification

Re: [PATCH] lower-bitint: Fix .{ADD,SUB,MUL}_OVERFLOW with _BitInt large/huge INTEGER_CST arguments [PR113003]

On Thu, 14 Dec 2023, Jakub Jelinek wrote: > Hi! > > As shown in the testcase, .{ADD,SUB,MUL}_OVERFLOW calls are another > exception to the middle/large/huge _BitInt discovery through SSA_NAMEs > next to stores of INTEGER_CSTs to memory and their conversions to > floating point. > The calls can

Re: [PATCH 5/6] Allow poly_uint64 for group_size args to vector type query routines

On Thu, 14 Dec 2023, Richard Sandiford wrote: > Richard Biener writes: > > The following changes the unsigned group_size argument to a poly_uint64 > > one to avoid too much special-casing in callers for VLA vectors when > > passing down the effective maximum desirable vector size to vector > >

Re: [PATCH] middle-end: Fix up constant handling in emit_conditional_move [PR111260]

On Thu, Dec 14, 2023 at 6:42 PM Andrew Pinski (QUIC) wrote: > > > > -Original Message- > > From: Richard Biener > > Sent: Thursday, December 14, 2023 5:23 AM > > To: Andrew Pinski (QUIC) > > Cc: gcc-patches@gcc.gnu.org > > Subject: Re: [PATCH] middle-end: Fix up constant handling in > >

Re: [PATCH #2/2] strub: sparc64: unbias the stack address [PR112917]

On Thu, Dec 14, 2023 at 10:29 PM Alexandre Oliva wrote: > > > The stack pointer is biased by 2047 bytes on sparc64, so the range it > delimits is way off. Unbias the addresses returned by > __builtin_stack_address (), so that the strub builtins, inlined or > not, can function correctly. I've

Re: [PATCH v4] [tree-optimization/110279] Consider FMA in get_reassociation_width

On Thu, Dec 14, 2023 at 9:55 PM Di Zhao OS wrote: > > > > -Original Message- > > From: Richard Biener > > Sent: Wednesday, December 13, 2023 5:01 PM > > To: Di Zhao OS > > Cc: gcc-patches@gcc.gnu.org > > Subject: Re: [PATCH v4] [tree-optimization/110279] Consider FMA in > >

Re: [PATCH] strub: use opt_for_fn during ipa

On Thu, 14 Dec 2023, Alexandre Oliva wrote: > > Instead of global optimization levels and flags, check per-function > ones. > > Regstrapped on x86_64-linux-gnu, also testing on sparc-solaris2.11.3. > Ok to install? You have to be generally careful when working within IPA with function bodies

Re: [PATCH] strub: avoid lto inlining

On Thu, Dec 14, 2023 at 8:53 PM Alexandre Oliva wrote: > > > The strub builtins are not suited for cross-unit inlining, they should > only be inlined by the builtin expanders, if at all. While testing on > sparc64, it occurred to me that, if libgcc was built with LTO enabled, > lto1 might inline

RE: [PATCH v7] libgfortran: Replace mutex with rwlock

On 2023/12/14 20:39, Jakub Jelinek wrote: > On Thu, Dec 14, 2023 at 01:29:01PM +0100, Thomas Schwinge wrote: >>> Sure, I will look into that. >>> >>> BTW, I didn’t have the PowerPC in hands, do you mind granting the access of >>> your >>> test environment to me to help reproduce the issue? >> >>

Re: [PATCH V2] rs6000: Change GPR2 to volatile & non-fixed register for function that does not use TOC [PR110320]

On 12/14/23 9:57 PM, Peter Bergner wrote: > On 7/16/23 10:40 PM, P Jeevitha via Gcc-patches wrote: >> + /* For non PC-relative code, GPR2 is unavailable for register allocation. >> */ >> + if (FIXED_R2 && !rs6000_pcrel_p ()) >> +fixed_regs[2] = 1; [snip] > On a related note, Jeevitha's

Re: [PATCH V2] rs6000: Change GPR2 to volatile & non-fixed register for function that does not use TOC [PR110320]

On 7/16/23 10:40 PM, P Jeevitha via Gcc-patches wrote: > Normally, GPR2 is the TOC pointer and is defined as a fixed and non-volatile > register. However, it can be used as volatile for PCREL addressing. Therefore, > modified r2 to be non-fixed in FIXED_REGISTERS and set it to fixed if it is >

[PATCH] testsuite: Require dfp for pr112943.c

Hi, As Coudert points out, this test fails on darwin as it does not support _Decimal64, so require dfp for it. Pushed as obvious fix. gcc/testsuite/ChangeLog: * gcc.target/i386/pr112943.c: Require dfp. --- gcc/testsuite/gcc.target/i386/pr112943.c | 2 +- 1 file changed, 1

[PATCH] RISC-V: Fix vmerge optimization bug in vec_perm vectorization

This patch fixes the following FAILs in "full coverage" testing: Running target riscv-sim/-march=rv64gcv_zvl256b/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-lmul=m8/--param=riscv-autovec-preference=fixed-vlmax FAIL: gcc.dg/vect/vect-strided-mult-char-ls.c -flto -ffat-lto-objects execution

[PATCH] i386: Allow 64 bit mask register for -mno-evex512

Hi all, There is a recent change in AVX10 documentation which allows 64 bit mask register instructions in AVX10-256, the documentation comes following: Intel Advanced Vector Extensions 10 (Intel AVX10) Architecture Specification https://cdrdv2.intel.com/v1/dl/getContent/784267 The Converged

Re: [PATCH] i386: Sync move_max/store_max with prefer-vector-width [PR112824]

On Thu, Dec 14, 2023 at 3:54 PM Hongyu Wang wrote: > > Hi, > > Currently move_max follows the tuning feature first, but ideally it > should sync with prefer-vector-width when it is explicitly set to keep > vector move and operation with same vector size. > > Bootstrapped/regtested on

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

在 2023-12-14四的 20:27 +0800，chenglulu写道： > > > > > > > > 转发的消息 > > > > 主题: > [PATCH v2] extend.texi: Fix typos in LSX intrinsics > > > 日期: > Wed, 13

Re: Re: [PATCH] RISC-V: Add Zvfbfmin extension to the -march= option

2023-12-13 11:55  Palmer Dabbelt wrote: >   >On Tue, 12 Dec 2023 19:24:51 PST (-0800), zengx...@eswincomputing.com wrote: >> This patch would like to add new sub extension (aka Zvfbfmin) to the >> -march= option. It introduces a new data type BF16. >> >> Depending on different usage scenarios,

Re: Re: [PING^1][PATCH] RISC-V: Add Zvfbfmin extension to the -march= option

2023-12-15 09:27  juzhe.zhong wrote: >   >CCing Kito. > >I am sorry I can't review ABI even though it is vector related, this patch >needs kito's review. Thank you for a reminder In fact, in , Palmer Dabbelt has already

Re: [PING^1][PATCH] RISC-V: Add Zvfbfmin extension to the -march= option

CCing Kito. I am sorry I can't review ABI even though it is vector related, this patch needs kito's review. But I will be available on reviewing the following real vector BF16 intrinsic and auto-vectorization support. Thanks. juzhe.zh...@rivai.ai From: Xiao Zeng Date: 2023-12-15 09:22

Re: [PATCH] c++: abi_tag attribute on templates [PR109715]

On 12/14/23 19:59, Patrick Palka wrote: On Thu, 14 Dec 2023, Jason Merrill wrote: On 12/14/23 16:08, Patrick Palka wrote: On Thu, 14 Dec 2023, Jason Merrill wrote: On 12/14/23 14:17, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? Do we

[r14-6559 Regression] FAIL: gcc.dg/guality/pr58791-4.c -Os -DPREVENT_OPTIMIZATION line pr58791-4.c:32 i == 486 on Linux/x86_64

On Linux/x86_64, 8afdbcdd7abe1e3c7a81e07f34c256e7f2dbc652 is the first bad commit commit 8afdbcdd7abe1e3c7a81e07f34c256e7f2dbc652 Author: Di Zhao Date: Fri Dec 15 03:22:32 2023 +0800 Consider fully pipelined FMA in get_reassociation_width caused FAIL: gcc.dg/guality/pr58791-4.c -O2

[PING^1][PATCH] RISC-V: Add Zvfbfmin extension to the -march= option

This patch would like to add new sub extension (aka Zvfbfmin) to the -march= option. It introduces a new data type BF16. Depending on different usage scenarios, the Zvfbfmin extension may depend on 'V' or 'Zve32f'. This patch only implements dependencies in scenario of Embedded Processor. In

Re: [committed] libstdc++: Implement C++23 header [PR107760]

On Thu, Dec 14, 2023 at 6:05 PM Jonathan Wakely wrote: > Tested x86_64-linux. Pushed to trunk. > > -- >8 -- > > This adds the C++23 std::print functions, which use std::format to write > to a FILE stream or std::ostream (defaulting to stdout). > > The new extern symbols are in the libstdc++exp.a

Re: [PATCH] c++: abi_tag attribute on templates [PR109715]

On Thu, 14 Dec 2023, Jason Merrill wrote: > On 12/14/23 16:08, Patrick Palka wrote: > > On Thu, 14 Dec 2023, Jason Merrill wrote: > > > > > On 12/14/23 14:17, Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > > > trunk? Do we want to

Re: [PATCH 0/4] v3 of: Option handling: add documentation URLs

Hi David, On Thu, Dec 14, 2023 at 10:01:39AM -0500, David Malcolm wrote: > > Once your patch is in please feel free to sent an email to > > build...@sourceware.org > > https://sourceware.org/mailman/listinfo/buildbot > > And we'll add the above build steps and update the autotools > >

Re: Re: [PATCH] Middle-end: Do not model address cost for SELECT_VL style vectorization

Thanks Richard. Committed. juzhe.zh...@rivai.ai From: Richard Biener Date: 2023-12-14 23:10 To: Juzhe-Zhong CC: gcc-patches; richard.sandiford Subject: Re: [PATCH] Middle-end: Do not model address cost for SELECT_VL style vectorization On Thu, 14 Dec 2023, Juzhe-Zhong wrote: > Follow

Re: [PR target/110201] Fix operand types for various scalar crypto insns

On Fri, Dec 15, 2023 at 12:36 AM Jeff Law wrote: > > > > On 12/14/23 02:46, Christoph Müllner wrote: > > On Tue, Jun 20, 2023 at 12:34 AM Jeff Law via Gcc-patches > > wrote: > >> > >> > >> A handful of the scalar crypto instructions are supposed to take a > >> constant integer argument 0..3

[committed] libstdc++: Implement C++23 header [PR107760]

Tested x86_64-linux. Pushed to trunk. -- >8 -- This adds the C++23 std::print functions, which use std::format to write to a FILE stream or std::ostream (defaulting to stdout). The new extern symbols are in the libstdc++exp.a archive, so we aren't committing to stable symbols in the DSO yet.

[committed] libstdc++: Fix filebuf::native_handle() for Windows

Tested x86_64-linux. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_CHECK_FILEBUF_NATIVE_HANDLES): Add missing header to configure test. Check correct variable. * config/io/basic_file_stdio.cc (__basic_file::native_handle): Fix typo.

[committed] libstdc++: Tweaks for std::format fast path

Tested x86_64-linux. Pushed to trunk. -- >8 -- Fix an incorrect call to _Sink::_M_reserve() which should have passed the __n parameter. This was not actually a problem because it was in an discarded statement, because only the _Seq_sink> specialization was used. Also add some branch prediction

[committed] libstdc++: Fix %S format of duration with floating-point rep

Tested x86_64-linux. Pushed to trunk. Backport needed too. -- >8 -- I got the order of arguments to std::format_to wrong. It was in a discarded statement, for a case which wasn't being tested. libstdc++-v3/ChangeLog: * include/bits/chrono_io.h (__formatter_chrono::_M_S): Fix order

[committed] libstdc++: Add dg-output to two tests

Tested x86_64-linux. Pushed to trunk. -- >8 -- These tests are expected to run interactively, with the output checked by eye. Nobody ever does that, but we can at least use dg-output to check that the output is as expected. libstdc++-v3/ChangeLog: * testsuite/27_io/objects/char/2.cc:

Re: [PR target/110201] Fix operand types for various scalar crypto insns

On 12/14/23 02:46, Christoph Müllner wrote: On Tue, Jun 20, 2023 at 12:34 AM Jeff Law via Gcc-patches wrote: A handful of the scalar crypto instructions are supposed to take a constant integer argument 0..3 inclusive. A suitable constraint was created and used for this purpose (D03), but

Re: [PATCH 1/2] libstdc++: Atomic wait/notify ABI stabilization

On Thu, 14 Dec 2023, Thomas Rodgers wrote: I need to look at this a bit more (and not on my phone, at lunch). Ultimately, C++26 expects to add predicate waits and returning a ‘tri-state’ result isn’t something that’s been considered or likely to be approved. Ok, then that seems to fit best

[PATCH] match.pd: Optimize sign-extension followed by truncation [PR113024]

Hi! While looking at a bitint ICE, I've noticed we don't optimize in f1 and f5 functions below the 2 casts into just one at GIMPLE, even when optimize it in convert_to_integer if it appears in the same stmt. The large match.pd simplification of two conversions in a row has many complex rules and

[Committed] RISC-V: Tweak generic vector COST model

Notice current generic vector cost model make PR112387 failed to vectorize. Adapt it same as ARM SVE generic vector cost model which can fix it. Committed as it is obvious fix. PR target/112387 gcc/ChangeLog: * config/riscv/riscv.cc: Adapt generic cost model same ARM SVE.

Re: [PATCH 1/2] libstdc++: Atomic wait/notify ABI stabilization

I need to look at this a bit more (and not on my phone, at lunch). Ultimately, C++26 expects to add predicate waits and returning a ‘tri-state’ result isn’t something that’s been considered or likely to be approved. On Mon, Dec 11, 2023 at 12:18 PM Jonathan Wakely wrote: > CCing Tom's current

[Committed] RISC-V: Adjust test

Since middle-end patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640595.html will change vectorization code. Adapt tests for ths patch. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/pr112988-1.c: Adapt test. ---

[PATCH] bitint: Introduce abi_limb_mode

Hi! Given what I saw in the aarch64/arm psABIs for BITINT_TYPE, as I said earlier I'm afraid we need to differentiate between the limb mode/precision specified in the psABIs (what is used to decide how it is actually passed, aligned or what size it has) vs. what limb mode/precision should be used

[PATCH] lower-bitint: Fix .{ADD,SUB,MUL}_OVERFLOW with _BitInt large/huge INTEGER_CST arguments [PR113003]

Hi! As shown in the testcase, .{ADD,SUB,MUL}_OVERFLOW calls are another exception to the middle/large/huge _BitInt discovery through SSA_NAMEs next to stores of INTEGER_CSTs to memory and their conversions to floating point. The calls can have normal COMPLEX_TYPE with INTEGER_TYPE elts return

Re: [PATCH] c++: abi_tag attribute on templates [PR109715]

On 12/14/23 16:08, Patrick Palka wrote: On Thu, 14 Dec 2023, Jason Merrill wrote: On 12/14/23 14:17, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? Do we want to condition this on abi_check (19)? I think we do, sadly. Sounds good,

Re: [PATCH] RISC-V: Add -fno-vect-cost-model to pr112773 testcase

LGTM juzhe.zh...@rivai.ai From: Patrick O'Neill Date: 2023-12-15 05:32 To: gcc-patches CC: rdapp.gcc; juzhe.zhong; Patrick O'Neill Subject: [PATCH] RISC-V: Add -fno-vect-cost-model to pr112773 testcase The testcase for pr112773 started passing after r14-6472-g8501edba91e which was before the

[pushed] testsuite: move more analyzer test cases to c-c++-common (3) [PR96395]

Move a further 268 tests from gcc.dg/analyzer to c-c++-common/analyzer. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r14-6564-gae034b9106fbdd. gcc/testsuite/ChangeLog: PR analyzer/96395 * c-c++-common/analyzer/analyzer-decls.h: New header.

[COMMITTED] middle-end: Fix up constant handling in emit_conditional_move [PR111260]

After r14-2667-gceae1400cf24f329393e96dd9720, we force a constant to a register if it is shared with one of the other operands. The problem is used the comparison mode for the register but that could be different from the operand mode. This causes some issues on some targets. To fix it, we need

[PATCH] RISC-V: Add -fno-vect-cost-model to pr112773 testcase

The testcase for pr112773 started passing after r14-6472-g8501edba91e which was before the actual fix. This patch adds -fno-vect-cost-model which prevents the testcase from passing due to the vls change. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/partial/pr112773.c: Add

[PATCH #2/2] strub: sparc64: unbias the stack address [PR112917]

The stack pointer is biased by 2047 bytes on sparc64, so the range it delimits is way off. Unbias the addresses returned by __builtin_stack_address (), so that the strub builtins, inlined or not, can function correctly. I've considered introducing a new target macro, but using

Re: [PATCH] Fix tests for gomp

Hi! On 2023-12-13T12:09:14+0100, Jakub Jelinek wrote: > On Wed, Dec 13, 2023 at 11:03:50AM +, Andre Vieira (lists) wrote: >> Hmm I think I understand what you are saying, but I'm not sure I agree. >> So before I enabled simdclone testing for aarch64, this test had no target >> selectors.

Re: [V4] [PATCH 3/4] c23: aliasing of compatible tagged types

On Mon, 27 Nov 2023, Martin Uecker wrote: > diff --git a/gcc/c/c-tree.h b/gcc/c/c-tree.h > index a5dd9a37944..ece5b6a5d26 100644 > --- a/gcc/c/c-tree.h > +++ b/gcc/c/c-tree.h > @@ -758,6 +758,7 @@ extern tree require_complete_type (location_t, tree); > extern bool same_translation_unit_p

Re: [PATCH] c++: abi_tag attribute on templates [PR109715]

On Thu, 14 Dec 2023, Jason Merrill wrote: > On 12/14/23 14:17, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > trunk? Do we want to condition this on abi_check (19)? > > I think we do, sadly. Sounds good, like so? Bootstrap and regtest in

Re: [PATCH] c++: fix parsing with auto(x) at block scope [PR112482]

On 12/14/23 16:02, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. -- >8 -- This is sort of like r14-5514, but at block scope. Consider struct A { A(int, int); }; void g (int a) { A bar(auto(a), 42); // not a fn decl } where we

Update 'gcc.dg/vect/vect-simd-clone-*.c' GCN 'dg-warning's (was: [PATCH] aarch64: enable mixed-types for aarch64 simdclones)

Hi! On 2023-10-16T16:03:26+0100, "Andre Vieira (lists)" wrote: > --- a/gcc/testsuite/gcc.dg/vect/vect-simd-clone-1.c > +++ b/gcc/testsuite/gcc.dg/vect/vect-simd-clone-1.c > @@ -12,8 +12,13 @@ int array[N]; > > #pragma omp declare simd simdlen(4) notinbranch > #pragma omp declare simd

Re: [PATCH v4] c++: fix ICE with sizeof in a template [PR112869]

On 12/14/23 16:01, Marek Polacek wrote: On Wed, Dec 13, 2023 at 03:28:38PM -0500, Jason Merrill wrote: On 12/12/23 17:48, Marek Polacek wrote: On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote: On 12/8/23 16:15, Marek Polacek wrote: On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason

[PATCH] c++: fix parsing with auto(x) at block scope [PR112482]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This is sort of like r14-5514, but at block scope. Consider struct A { A(int, int); }; void g (int a) { A bar(auto(a), 42); // not a fn decl } where we emit error: 'auto' parameter not permitted in this context

Re: [PATCH] i386: Fix missed APX_NDD check for shift/rotate expanders [PR 112943]

The testcase fails on darwin: +FAIL: gcc.target/i386/pr112943.c (test for excess errors) because it does not support _Decimal64. /* { dg-do compile { target { ! ia32 } } } */ should be changed to: /* { dg-do compile { target { dfp && { ! ia32 } } } } */ Thanks, FX

[PATCH v4] c++: fix ICE with sizeof in a template [PR112869]

On Wed, Dec 13, 2023 at 03:28:38PM -0500, Jason Merrill wrote: > On 12/12/23 17:48, Marek Polacek wrote: > > On Fri, Dec 08, 2023 at 11:09:15PM -0500, Jason Merrill wrote: > > > On 12/8/23 16:15, Marek Polacek wrote: > > > > On Fri, Dec 08, 2023 at 12:09:18PM -0500, Jason Merrill wrote: > > > > >

Re: [V4] [PATCH 2/4] c23: tag compatibility rules for enums

On Mon, 27 Nov 2023, Martin Uecker wrote: > + enum B : short { M = 1 } *y2e = /* { dg-warning "incompatible" > } */ This probably now needs to be dg-error because -Wincompatible-pointer-types is now an error by default. OK with that changed as needed (you may also need such a change

RE: [PATCH v4] [tree-optimization/110279] Consider FMA in get_reassociation_width

> -Original Message- > From: Richard Biener > Sent: Wednesday, December 13, 2023 5:01 PM > To: Di Zhao OS > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH v4] [tree-optimization/110279] Consider FMA in > get_reassociation_width > > On Wed, Dec 13, 2023 at 9:14 AM Di Zhao OS >

Re: [V4] [C PATCH 1/4] c23: tag compatibility rules for struct and unions

On Mon, 27 Nov 2023, Martin Uecker wrote: > Note that there is an additional change in parser_xref_tag > to address the issue regarding completeness in redefinition > which affects also structs / unions. The test c23-tag-6.c > was changed accordingly. > > > c23: tag compatibility rules for

Re: [PATCH 5/6] Allow poly_uint64 for group_size args to vector type query routines

Richard Biener writes: > The following changes the unsigned group_size argument to a poly_uint64 > one to avoid too much special-casing in callers for VLA vectors when > passing down the effective maximum desirable vector size to vector > type query routines. The intent is to be able to pass

Re: [PATCH] c++: section attribute on templates [PR70435, PR88061]

On 12/14/23 14:17, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. -- >8 -- The section attribute currently has no effect on templates because the call to set_decl_section_name only happens at parse time and not also at instantiation

Re: [PATCH] c++: abi_tag attribute on templates [PR109715]

On 12/14/23 14:17, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? Do we want to condition this on abi_check (19)? I think we do, sadly. -- >8 -- As with other declaration attributes, we need to look through TEMPLATE_DECL when looking up

[PATCH #1/2] strub: sparc: omit frame in strub_leave [PR112917]

If we allow __strub_leave to allocate a frame on sparc, it will overlap with a lot of the stack range we're supposed to scrub, because of the large fixed-size outgoing args and register save area. Unfortunately, setting up the PIC register seems to prevent the frame pointer from being omitted.

Re: [PATCH] hardened: use LD_PIE_SPEC only if defined

On Thu, Dec 14, 2023 at 04:50:49PM -0300, Alexandre Oliva wrote: > > sol2.h may define LINK_PIE_SPEC and leave LD_PIE_SPEC undefined, but > gcc.cc will only provide a LD_PIE_SPEC definition if LINK_PIE_SPEC is > not defined, and then it uses LD_PIE_SPEC guarded by #ifdef HAVE_LD_PIE > only. Add

[PATCH] strub: use opt_for_fn during ipa

Instead of global optimization levels and flags, check per-function ones. Regstrapped on x86_64-linux-gnu, also testing on sparc-solaris2.11.3. Ok to install? (sorry, Richi, I dropped the ball and failed to fix this before the monster commit) for gcc/ChangeLog * ipa-strub.cc

[PATCH] strub: avoid lto inlining

The strub builtins are not suited for cross-unit inlining, they should only be inlined by the builtin expanders, if at all. While testing on sparc64, it occurred to me that, if libgcc was built with LTO enabled, lto1 might inline them, and that would likely break things. So, make sure they're

[PATCH] hardened: use LD_PIE_SPEC only if defined

sol2.h may define LINK_PIE_SPEC and leave LD_PIE_SPEC undefined, but gcc.cc will only provide a LD_PIE_SPEC definition if LINK_PIE_SPEC is not defined, and then it uses LD_PIE_SPEC guarded by #ifdef HAVE_LD_PIE only. Add LD_PIE_SPEC to the guard. Regstrapped on x86_64-linux-gnu; also testing

Re: [PATCH v2] aarch64: Fix +nopredres, +nols64 and +nomops

Andrew Carlotti writes: > On Sat, Dec 09, 2023 at 07:22:49PM +, Richard Sandiford wrote: >> Andrew Carlotti writes: >> > ... >> >> This is the only use of native_detect_p, so it'd be good to remove >> the field itself. > > Done > >> > ... >> > >> > @@ -447,6 +451,13 @@

Re: [PATCH 17/21]AArch64: Add implementation for vector cbranch for Advanced SIMD

Tamar Christina writes: >> I see you've changed it from: >> >> + rtx cc_reg = aarch64_gen_compare_reg (code, val, const0_rtx); >> + rtx cmp_rtx = gen_rtx_fmt_ee (code, DImode, cc_reg, const0_rtx); >> + emit_jump_insn (gen_condjump (cmp_rtx, cc_reg, operands[3])); >> >> to: >> >> +

Re: [PATCH] RISC-V: fix scalar crypto pattern

On 12/14/23 04:12, Liao Shihua wrote: Sorry, I was not aware of this patch. Since Jeff's patch was here first and also includes more tests, I propose to move forward with his patch (but I'm not a maintainer!). Therefore, I've reviewed Jeff's patch and replied to his email. FWIW: Jeff's patch

Re: [PATCH] RISC-V: fix scalar crypto pattern

On 12/14/23 02:48, Christoph Müllner wrote: On Thu, Dec 14, 2023 at 1:40 AM Jeff Law wrote: On 12/13/23 02:03, Christoph Müllner wrote: On Wed, Dec 13, 2023 at 9:22 AM Liao Shihua wrote: In Scalar Crypto Built-In functions, some require immediate parameters, But register_operand are

Re: [PATCH] c++: section attribute on templates [PR70435, PR88061]

On Thu, Dec 14, 2023 at 02:17:25PM -0500, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk? LGTM. > -- >8 -- > > The section attribute currently has no effect on templates because the > call to set_decl_section_name only happens at parse

[PATCH] c++: section attribute on templates [PR70435, PR88061]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- The section attribute currently has no effect on templates because the call to set_decl_section_name only happens at parse time and not also at instantiation time. This patch fixes this by propagating the

[PATCH] c++: abi_tag attribute on templates [PR109715]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? Do we want to condition this on abi_check (19)? -- >8 -- As with other declaration attributes, we need to look through TEMPLATE_DECL when looking up the abi_tag attribute. PR c++/109715 gcc/cp/ChangeLog:

Re: [PATCH 1/2] emit-rtl, lra: Move lra's emit_inc to emit-rtl.cc

On 12/13/23 16:00, Alex Coplan wrote: Hi, In PR112906 we ICE because we try to use force_reg to reload an auto-increment address, but force_reg can't do this. With the aim of fixing the PR by supporting reloading arbitrary addresses in pre-RA splitters, this patch generalizes

RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for codegen of exit code

> -Original Message- > From: Richard Biener > Sent: Thursday, December 14, 2023 1:13 PM > To: Tamar Christina > Cc: Richard Sandiford ; gcc-patches@gcc.gnu.org; > nd ; j...@ventanamicro.com > Subject: RE: [PATCH 9/21]middle-end: implement vectorizable_early_exit for > codegen of exit

[patch, fortran, committed] PR112873 F2023 degree trig functions

The following has been committed per discussion in the subject PR. commit 95b70545331764c85079a1d0e1e19b605bda1456 (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Wed Dec 13 19:04:50 2023 -0800 fortran: Add degree based trig functions for F2023 PR

RE: [PATCH 17/21]AArch64: Add implementation for vector cbranch for Advanced SIMD

> I see you've changed it from: > > + rtx cc_reg = aarch64_gen_compare_reg (code, val, const0_rtx); > + rtx cmp_rtx = gen_rtx_fmt_ee (code, DImode, cc_reg, const0_rtx); > + emit_jump_insn (gen_condjump (cmp_rtx, cc_reg, operands[3])); > > to: > > + emit_jump_insn (gen_cbranchdi4

Re: [PATCH] c++: Implement P2582R1, CTAD from inherited constructors

On Wed, Dec 13, 2023 at 08:48:49PM -0500, Jason Merrill wrote: > On 11/27/23 10:58, Patrick Palka wrote: > > gcc/cp/ChangeLog: > > > > * cp-tree.h (type_targs_deducible_from): Adjust return type. > > * pt.cc (alias_ctad_tweaks): Handle C++23 inherited CTAD. > >

RE: [PATCH] middle-end: Fix up constant handling in emit_conditional_move [PR111260]

> -Original Message- > From: Richard Biener > Sent: Thursday, December 14, 2023 5:23 AM > To: Andrew Pinski (QUIC) > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] middle-end: Fix up constant handling in > emit_conditional_move [PR111260] > > On Wed, Dec 13, 2023 at 5:51 PM Andrew

Re: [PATCH] doc: Document AArch64-specific asm operand modifiers

Alex Coplan writes: > Hi, > > As it stands, GCC doesn't document any public AArch64-specific operand > modifiers for use in inline asm. This patch fixes that by documenting > an initial set of public AArch64-specific operand modifiers. > > Tested with make html and checking the output looks OK

Re: [PATCH v3] AArch64: Add inline memmove expansion

Sorry, only just realised that I've never replied to this :( Wilco Dijkstra writes: > Hi Richard, > >> + rtx load[max_ops], store[max_ops]; >> >> Please either add a comment explaining why 40 is guaranteed to be >> enough, or (my preference) use: >> >> auto_vec, ...> ops; > > I've changed to

[PATCH] doc: Document AArch64-specific asm operand modifiers

Hi, As it stands, GCC doesn't document any public AArch64-specific operand modifiers for use in inline asm. This patch fixes that by documenting an initial set of public AArch64-specific operand modifiers. Tested with make html and checking the output looks OK in a browser. OK for trunk?

Re: [PATCH] libstdc++: Make __gnu_debug::vector usable in constant expressions [PR109536]

On Wed, 6 Dec 2023 at 14:30, Jonathan Wakely wrote: > > Any comments on this approach? Pushed to trunk now. > > -- >8 -- > > This makes constexpr std::vector (mostly) work in Debug Mode. All safe > iterator instrumentation and checking is disabled during constant > evaluation, because it

Re: [PATCH] expmed: Get vec_extract element mode from insn_data, [PR112999]

Robin Dapp writes: >> It looks like: >> >> FOR_EACH_MODE_FROM (new_mode, new_mode) >> if (known_eq (GET_MODE_SIZE (new_mode), GET_MODE_SIZE (GET_MODE (op0))) >> && known_eq (GET_MODE_UNIT_SIZE (new_mode), GET_MODE_SIZE (tmode)) >> && targetm.vector_mode_supported_p

Re: [PATCH] expmed: Get vec_extract element mode from insn_data, [PR112999]

> It looks like: > > FOR_EACH_MODE_FROM (new_mode, new_mode) > if (known_eq (GET_MODE_SIZE (new_mode), GET_MODE_SIZE (GET_MODE (op0))) > && known_eq (GET_MODE_UNIT_SIZE (new_mode), GET_MODE_SIZE (tmode)) > && targetm.vector_mode_supported_p (new_mode) >

[PATCH] tree-optimization/113018 - ICE with BB reduction vectorization

When BB reduction vectorization picks up a chain with an ASM def in it and that's inside the vectorized region we fail to get its LHS. Instead of trying to get the correct def the following avoids vectorizing such def and instead keeps it as def to add in the epilog. Bootstrapped and tested on

Re: [PATCH v7] libgfortran: Replace mutex with rwlock

On 09/12/2023 15:39, Lipeng Zhu wrote: > This patch try to introduce the rwlock and split the read/write to > unit_root tree and unit_cache with rwlock instead of the mutex to > increase CPU efficiency. In the get_gfc_unit function, the percentage > to step into the insert_unit function is around

Re: [PATCH] Middle-end: Do not model address cost for SELECT_VL style vectorization

On Thu, 14 Dec 2023, Juzhe-Zhong wrote: > Follow Richard's suggestions, we should not model address cost in the loop > vectorizer for select_vl or decrement IV since other style vectorization > doesn't > do that. > > To make cost model comparison apple to apple. > This patch set COST from 2 to

Re: [committed] d: Merge upstream dmd, druntime 2bbf64907c, phobos b64bfbf91

Thomas Schwinge writes: > On 2023-12-11T11:13:28+0100, Iain Buclaw wrote: >> Excerpts from Iain Buclaw's message of Dezember 11, 2023 11:07 am: >>> This patch merges the D front-end and runtime library with upstream dmd >>> 2bbf64907c, and the standard library with phobos b64bfbf91. >>> >>>

[PATCH] tree-optimization/112793 - SLP of constant/external code-generated twice

The following makes the attempt at code-generating a constant/external SLP node twice well-formed as that can happen when partitioning BB vectorization attempts where we keep constants/externals unpartitioned. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR

[COMMITTED 2/4] libgrust: Add entry for maintainers

From: Pierre-Emmanuel Patry ChangeLog: * MAINTAINERS: Add maintainers for libgrust. contrib/ChangeLog: * gcc-changelog/git_commit.py: Add libgrust. Co-authored-by: Arthur Cohen Signed-off-by: Pierre-Emmanuel Patry --- MAINTAINERS | 1 +

[COMMITTED 4/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. Disable target libgrust if we're not building target libstdc++. ChangeLog: * Makefile.def: Add libgrust as host & target module. * configure.ac: Add libgrust to host

[PATCH 1/4; v3] options: add gcc/regenerate-opt-urls.py

Changed in v3: - Makefile.in: added OPT_URLS_HTML_DEPS and a comment Changed in v2: - added convenience targets to Makefile for regenerating the .opt.urls files, and for running unit tests for the generation code - parse gdc and gfortran documentation, and create LangUrlSuffix_{lang} directives

[COMMITTED 1/4] libgrust: Add ChangeLog file

From: Pierre-Emmanuel Patry libgrust/ChangeLog: * ChangeLog: New file. Signed-off-by: Pierre-Emmanuel Patry --- libgrust/ChangeLog | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 libgrust/ChangeLog diff --git a/libgrust/ChangeLog b/libgrust/ChangeLog new file mode

[PATCH 4/4; v2] options: wire up options-urls.cc into gcc_urlifier

Changed in v2: - split out from the code that generates options-urls.cc - call the generated function, rather than use a generated array - pass around lang_mask gcc/ChangeLog: * diagnostic.h (diagnostic_make_option_url_cb): Add lang_mask param.

[PATCH 3/4; v2] opts: add logic to generate options-urls.cc

Changed in v2: - split out from the code that uses this - now handles lang-specific URLs, as well as generic URLs - the generated options-urls.cc now contains a function with a switch statement, rather than an array, to support lang-specific URLs: const char * get_opt_url_suffix (int

[PATCH 0/4] v3 of: Option handling: add documentation URLs

> Hi David, > > On Fri, Dec 08, 2023 at 06:35:56PM -0500, David Malcolm wrote: > > On Tue, 2023-11-21 at 23:43 +, Joseph Myers wrote: > > > On Tue, 21 Nov 2023, Tobias Burnus wrote: > > > > > > > On 21.11.23 14:57, David Malcolm wrote: > > > > > On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter

[COMMITTED] Initial libgrust build patches

Hi, This patchset contains the initial changes to add the libgrust folder to gcc, which will later contain libraries used by our Rust frontend. This work was done by Pierre-Emmanuel Patry as part of his work on supporting procedural macros in our frontend. It was then tested by Thomas Schwinge,

Re: [PATCH v3 4/5] Add support for target_version attribute

Andrew Carlotti writes: > This patch adds support for the "target_version" attribute to the middle > end and the C++ frontend, which will be used to implement function > multiversioning in the aarch64 backend. > > On targets that don't use the "target" attribute for multiversioning, > there is no

  1   2   >