[PATCH] Avoid cfg corruption when using sjlj exceptions where loops are present in the assign_params emitted code.

bootstrapped on x86_64-pc-linux-gnu.Avoid cfg corruption when using sjlj exceptions where loops are present in the assign_params emitted code. 2024-08-06 Joern Rennecke gcc/ * except.cc (sjlj_emit_function_enter): Set fn_begin_outside_block again if encountering a jump instru

[PATCH] i386: Fix up __builtin_ia32_b{extr{,i}_u{32,64},zhi_{s,d}i} folding [PR116287]

Hi! The GENERIC folding of these builtins have cases where it folds to a constant regardless of the value of the first operand. If so, we need to use omit_one_operand to avoid throwing away side-effects in the first operand if any. The cases which verify the first argument is INTEGER_CST don't n

[committed] c-family: Add some more ARRAY_SIZE uses

Hi! These two spots were just non-standard, because they divided sizeof (omp_pragmas_simd) by sizeof (*omp_pragmas) and not the expected sizeof (*omp_pragmas_simd) and so weren't converted into ARRAY_SIZE. Both of the latter sizes are the same though, as both arrays have the same type, so this pa

[PATCH] aarch64: Emit ADD X, Y, Y instead of SHL X, Y, #1 for Advanced SIMD

Hi all, On many cores, including Neoverse V2 the throughput of vector ADD instructions is higher than vector shifts like SHL. We can lean on that to emit code like: add v0.4s, v0.4s, v0.4s instead of: shl v0.4s, v0.4s, 1 LLVM already does this trick. In RTL the code gets canonincalis

Re: [committed] c-family: Add some more ARRAY_SIZE uses

On Fri, Aug 9, 2024 at 12:39 AM Jakub Jelinek wrote: > > Hi! > > These two spots were just non-standard, because they divided > sizeof (omp_pragmas_simd) by sizeof (*omp_pragmas) and not > the expected sizeof (*omp_pragmas_simd) and so weren't converted > into ARRAY_SIZE. Both of the latter sizes

[PATCH] c++: Don't accept multiple enum definitions within template class [PR115806]

We have been accepting the following invalid code since revision 557831a91df === cut here === template struct S { enum E { a }; enum E { b }; }; S s; === cut here === The problem is that start_enum will set OPAQUE_ENUM_P to true even if it retrieves an existing definition for the enum, which

[PATCH] RISC-V: Bugfix for RVV rounding intrinsic ICE in function checker

When compiling an interface for rounding of type 'vfloat16*' without using zvfh or zvfhmin, it is not enough to use FLOAT_MODE_P because the type does not support it. Although the subsequent riscv_validate_vector_type checks will still fail and throw exceptions, I don't think we should have ICE he

[PING] [PATCH] c: Diagnose declarations that are used only in their own initializer [PR115027]

ok? Am Samstag, dem 29.06.2024 um 20:30 +0200 schrieb Martin Uecker: > Probably not entirely fool-proof when using statement > expressions in initializers, but should be good enough. > > > Bootstrapped and regression tested on x86_64. > > > > c: Diagnose declarations that are used only

Re: [PATCH v3 1/2] aarch64: Add AdvSIMD faminmax intrinsics

Hi Kyrill, On 8/8/2024 4:23 PM, Kyrylo Tkachov wrote: Hi Saurabh, On 7 Aug 2024, at 17:11, saurabh@arm.com wrote: External email: Use caution opening links or attachments The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and mandatory from Armv9.5-a. It introduces instructi

Re: [PATCH v3 2/2] aarch64: Add codegen support for AdvSIMD faminmax

> On 7 Aug 2024, at 17:11, saurabh@arm.com wrote: > > External email: Use caution opening links or attachments > > > The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and > mandatory from Armv9.5-a. It introduces instructions for computing the > floating point absolute maximu

[PATCH 0/5] Address std::find regression with RTL unrolling [PR116140]

This patch series aims to address PR116140. The regression in xalancbmk (both in SPEC 2006 and SPEC 2017) occurred when removing the hand-unrolling in std::__find_if in libstdc++. Keeping the loop re-rolled in the source is desirable as it allows the function to be vectorized with WIP vectorizer

[PATCH 2/5] testsuite: Add scan-ltrans-rtl for use in dg-final [PR116140]

This extends the scan-ltrans-tree* helpers to create RTL variants. This is needed to check the behaviour of an RTL pass under LTO. In particular it's used by a later patch in the series to check that RTL unrolling is applied under LTO. Tested as a series on aarch64-linux-gnu, OK for trunk? gcc/

[PATCH 3/5] testsuite: Ensure ltrans dump files get cleaned up properly [PR116140]

I noticed while working on a test that uses LTO and requests a dump file, that we are failing to cleanup ltrans dump files in the testsuite. E.g. the test I was working on compiles with -flto -fdump-rtl-loop2_unroll, and we end up with the following file: ./gcc/testsuite/g++/pr116140.ltrans0.ltra

[PATCH 1/5] cp: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

For the testcase added with this patch, we would end up losing the: #pragma GCC unroll 4 and emitting "warning: ignoring loop annotation". That warning comes from tree-cfg.cc:replace_loop_annotate, and means that we failed to process the ANNOTATE_EXPR in tree-cfg.cc:replace_loop_annotate_in_bl

[PATCH 5/5] libstdc++: Restore unrolling in std::find using pragma [PR116140]

Together with the preparatory compiler patches, this patch restores unrolling in std::__find_if, but this time relying on the compiler to do it by using: #pragma GCC unroll 4 which should restore the majority of the regression relative to the hand-unrolled version while still being vectorizable

[PATCH 4/5] lto: Set has_unroll flag when streaming in for LTO [PR116140]

When #pragma GCC unroll is processed in tree-cfg.cc:replace_loop_annotate_in_block, we set both the loop->unroll field (which is currently streamed out and back in during LTO) but also the cfun->has_unroll flag. cfun->has_unroll, however, is not currently streamed during LTO, so this patch attempt

Re: [PATCH] RISC-V: Bugfix for RVV rounding intrinsic ICE in function checker

> When compiling an interface for rounding of type 'vfloat16*' without using > zvfh > or zvfhmin, it is not enough to use FLOAT_MODE_P because the type does not > support > it. Although the subsequent riscv_validate_vector_type checks will still fail > and throw exceptions, I don't think we shoul

[PATCH] testsuite, rs6000: Remove all powerpc-*paired* uses

Hi, Similar to r15-710-g458b23bc8b3e2b which removed all uses of powerpc-*-linux*paired*, this patch is to remove the remaining powerpc-*paired* uses which I missed to catch with "*linux*" in search keyword. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and

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

Hi, Commit r15-2084 exposes one ICE in LRA. Firstly, before r15-2084 KFmode has 126 bit precision while V1TImode has 128 bit precision, so the subreg (subreg:V1TI (reg:KF 131) 0) is paradoxical_subreg_p, which stops some passes from doing some optimization. After r15-2084, KFmode has the same mo

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

Hi, As PR116266 shows, we miss TARGET_P10_VECTOR to guard those Power10 related vector instructions as well as their according built-in functions. This patch is to introduce TARGET_P10_VECTOR which is actually TARGET_POWER10 && TARGET_VSX underlying, it updates many places that should adopt TARGE

[PATCH] testsuite: Fix fam-in-union-alone-in-struct-2.c with unsigned char [PR116148]

Hi, As PR116148#c7 shows, fam-in-union-alone-in-struct-2.c still fails on hppa which is a BE environment, but by checking more (also confirmed by John in PR116148#c12), it's due to that signedness of plain char on hppa is signed therefore the value of with_fam_3_v.a[7] "8f" get sign extended as "f

Re: [PATCH v2] c++: improve diagnostic of 'return's in coroutines

Jason Merrill writes: > On 8/8/24 4:29 PM, Arsen Arsenović wrote: >> Tested on x86_64-pc-linux-gnu. I have blinking tsan test results again, >> but I think they're bogus (I'll re-test on physical hardware before >> pushing if needed). >> I'm somewhat curious of we should do a similar change WRT

Re: [PATCH 1/4] rs6000, add testcases to the overloaded vec_perm built-in

Hi Carl, on 2024/8/8 01:15, Carl Love wrote: > > GCC maintainers: > > The following patch adds missing test cases for the overloaded vec_perm > built-in.  It also fixes and issue with printing the 128-bit values in the > DEBUG section that was noticed when adding the additional test cases. >

Re: [PATCH 2/4] rs6000, remove built-ins __builtin_vsx_vperm_8hi and, __builtin_vsx_vperm_8hi_uns

Hi Carl, on 2024/8/8 01:15, Carl Love wrote: > > GCC maintainers: > > The following patch removes two redundant built-ins __builtin_vsx_vperm_8hi > and __builtin_vsx_vperm_8hi_uns.  The built-ins are covered by the overloaded > vec_perm built-in. > > The patch has been tested on Power 10 LE a

Re: [PATCH 3/4] rs6000, Remove redundant built-in __builtin_vsx_xvcvuxwdp

Hi Carl, on 2024/8/8 01:15, Carl Love wrote: > > GCC maintainers: > > The patch removed the built-in __builtin_vsx_xvcvuxwdp as it is covered by > the overloaded vec_doubleo built-in. > > The patch has been tested on Power 10 LE and BE with no regressions. > > Please let me know if it is acce

Re: [PATCH v2] c++: improve diagnostic of 'return's in coroutines

> On 9 Aug 2024, at 11:03, Arsen Arsenović wrote: > > Jason Merrill writes: > >> On 8/8/24 4:29 PM, Arsen Arsenović wrote: >>> Tested on x86_64-pc-linux-gnu. I have blinking tsan test results again, >>> but I think they're bogus (I'll re-test on physical hardware before >>> pushing if neede

PING^5 [PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

Hi, Gentle ping this patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651025.html BR, Kewen >> on 2024/7/12 00:15, Martin Jambor wrote: >>> Hi, >>> >>> can I add myself to the bunch of people who are pinging this?  >>> Having >>> this in will make our life easier. >>> >>> Thanks a lot,

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

Hi, On Thu, Aug 08, 2024 at 02:07:50PM -0700, Andrew Pinski wrote: > On Fri, Aug 2, 2024 at 7:30 AM Jeff Law wrote: > > > 2024-08-01 Surya Kumari Jangala > > > > > > gcc/ > > > PR rtl-optimization/PR116028 > > > * lra-constraints.cc (split_reg): Spill register before call > > >

[patch,avr,applied] Tidy up code for __[x]load insns.

Applied the patchlet below. Johann -- AVR: Tidy up code for __[x]load insns. gcc/ * config/avr/avr.md (*load__libgcc, *xload__libgcc): Tidy up code.commit a90c74ab161eab09802920fbd894bf55bc4fa797 Author: Georg-Johann Lay Date: Fri Aug 9 12:15:28 2024 +0200 AVR: Tidy up

Re: [PATCH] i386: Fix up __builtin_ia32_b{extr{, i}_u{32, 64}, zhi_{s, d}i} folding [PR116287]

On Fri, Aug 9, 2024 at 9:29 AM Jakub Jelinek wrote: > > Hi! > > The GENERIC folding of these builtins have cases where it folds to a > constant regardless of the value of the first operand. If so, we need > to use omit_one_operand to avoid throwing away side-effects in the first > operand if any.

OpenMP: Constructors and destructors for "declare target" static aggregates: Fix effective-target keyword in test cases (was: [PATCH, v3] OpenMP: Constructors and destructors for "declare target" stat

Hi! On 2024-08-07T14:08:42+0200, Tobias Burnus wrote: > --- /dev/null > +++ b/libgomp/testsuite/libgomp.c++/static-aggr-constructor-destructor-1.C > +// { dg-additional-options -foffload-options=-fdump-tree-optimized { target > { offload_device_nvptx || offload_target_amdgcn } } } Note here: '

Re: [PATCH 4/5] lto: Set has_unroll flag when streaming in for LTO [PR116140]

> Am 09.08.2024 um 11:30 schrieb Alex Coplan : > > When #pragma GCC unroll is processed in > tree-cfg.cc:replace_loop_annotate_in_block, we set both the loop->unroll > field (which is currently streamed out and back in during LTO) but also > the cfun->has_unroll flag. > > cfun->has_unroll, ho

Re: [PATCH 4/5] lto: Set has_unroll flag when streaming in for LTO [PR116140]

On 09/08/2024 13:12, Richard Biener wrote: > > > > Am 09.08.2024 um 11:30 schrieb Alex Coplan : > > > > When #pragma GCC unroll is processed in > > tree-cfg.cc:replace_loop_annotate_in_block, we set both the loop->unroll > > field (which is currently streamed out and back in during LTO) but als

Re: [PATCH v3 2/7] OpenMP: middle-end support for dispatch + adjust_args

Paul-Antoine Arras wrote: This patch adds middle-end support for the `dispatch` construct and the `adjust_args` clause. The heavy lifting is done in `gimplify_omp_dispatch` and `gimplify_call_expr` respectively. For `adjust_args`, this mostly consists in emitting a call to `gomp_get_mapped_ptr` f

Re: [PATCH 1/2] ipa: Treat static constructors and destructors as non-local (PR 115815)

Hello, and ping please. Martin On Fri, Jul 26 2024, Martin Jambor wrote: > Hi, > > in PR 115815, IPA-SRA thought it had control over all invocations of a > (recursive) static destructor but it did not see the implied > invocation which led to the original being left behind and the > clean-up cod

Re: [PATCH 2/2] ipa: Move pass_ipa_cdtor_merge before pass_ipa_cp and pass_ipa_sra

Hello, and ping please. Martin On Fri, Jul 26 2024, Martin Jambor wrote: > Hi, > > when looking at PR 115815 we realized that it would make sense to make > calls to functions originally declared static constructors and > destructors created by pass_ipa_cdtor_merge visible to IPA-SRA. This > pat

[commit] amdgcn: Add padding to trampoline

This avoids a -Wpadded warning (testcase gcc.dg/20050607-1.c). gcc/ChangeLog: * config/gcn/gcn.cc (gcn_asm_trampoline_template): Add .align. * config/gcn/gcn.h (TRAMPOLINE_SIZE): Increase to 40. --- gcc/config/gcn/gcn.cc | 1 + gcc/config/gcn/gcn.h | 2 +- 2 files changed, 2 ins

Re: [commit] amdgcn: Re-enable trampolines

On 09/08/2024 07:53, Thomas Schwinge wrote: Hi Andrew! On 2024-08-08T13:50:17+, Andrew Stubbs wrote: Previously, trampolines worked on GCN3 devices, but the newer GCN5 devices had different permissions on the stack memory space we were using. That changed when we added the reverse-offload

Re: [PATCH] vect: Multistep float->int conversion only with no trapping math

Am Thu, Aug 08, 2024 at 02:06:44PM +0200 schrieb Richard Biener: > On Mon, Aug 5, 2024 at 4:02 PM Juergen Christ wrote: > > > > Am Mon, Aug 05, 2024 at 01:00:31PM +0200 schrieb Richard Biener: > > > On Fri, Aug 2, 2024 at 2:43 PM Juergen Christ > > > wrote: > > > > > > > > Do not convert floats

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

I am looking into this failure. Thanks, Surya On 09/08/24 2:37 am, Andrew Pinski wrote: > On Fri, Aug 2, 2024 at 7:30 AM Jeff Law wrote: >> >> >> >> On 8/1/24 4:12 AM, Surya Kumari Jangala wrote: >>> lra: emit caller-save register spills before call insn [PR116028] >>> >>> LRA emits insns to sav

Re: [PATCH v2 2/4] aarch64: Fix tme intrinsic availability

On Thu, Aug 08, 2024 at 04:48:38PM +0100, Richard Sandiford wrote: > Andrew Carlotti writes: > > The availability of tme intrinsics was previously gated at both > > initialisation time (using global target options) and usage time > > (accounting for function-specific target options). This patch r

[pushed] c-family: regenerate c.opt.urls

The addition of -Wtemplate-body in r15-2774-g596d1ed9d40b10 means we need to regenerate c.opt.urls. gcc/c-family/ChangeLog: * c.opt.urls: Regenerate. --- gcc/c-family/c.opt.urls | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls index

Re: [PATCH] testsuite: Fix fam-in-union-alone-in-struct-2.c with unsigned char [PR116148]

Hi, Kewen, Thanks for the patch, LGTM. Qing > On Aug 9, 2024, at 05:50, Kewen.Lin wrote: > > Hi, > > As PR116148#c7 shows, fam-in-union-alone-in-struct-2.c still > fails on hppa which is a BE environment, but by checking more > (also confirmed by John in PR116148#c12), it's due to that > si

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

Hi! v6: - Note that support for 0-length arrays is slightly broken. - Improve readability of is_top_array_vla(), without changing behavior. - Doc: Clarify that both types and expressions are accepted, and provide an example. [Joseph] - Doc: Wording improvements. [Joseph, Jens] - Tests:

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

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

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

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

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

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

Re: [PATCH] testsuite: Fix fam-in-union-alone-in-struct-2.c with unsigned char [PR116148]

"Kewen.Lin" writes: > Hi, > > As PR116148#c7 shows, fam-in-union-alone-in-struct-2.c still > fails on hppa which is a BE environment, but by checking more > (also confirmed by John in PR116148#c12), it's due to that > signedness of plain char on hppa is signed therefore the value > of with_fam_3_

Re: [Ping 2, Patch, Fortran, PR84244, v3] Fix ICE in recompute_tree_invariant_for_addr_expr, at tree.c:4535

Ping! On Wed, 17 Jul 2024 15:11:33 +0200 Andre Vehreschild wrote: > Hi all, > > and the last ping. > > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? > > Regards, > Andre > > On Thu, 11 Jul 2024 16:05:09 +0200 > Andre Vehreschild wrote: > > > Hi all, > > > > the attached

Re: [Ping, Fortran, Patch, coarray, PR84246, v2] Fix for [Coarray] ICE in conv_caf_send, at fortran/trans-intrinsic.c:1950

Ping! On Wed, 17 Jul 2024 15:15:51 +0200 Andre Vehreschild wrote: > Hi all, > > attached patch fixes an ICE in coarray code, where the coarray expression > already was a pointer, which confused the compiler. Furthermore have I removed > a rewrite to a caf_send late in the trans-phase. This is no

Re: [Ping, Fortran, Patch, PR77518, (coarray), v3] Fix ICE in sizeof(coarray)

Ping! @Paul, you already had a look at this patch, but I made some changes. Or they ok? - Andre On Fri, 19 Jul 2024 13:26:21 +0200 Andre Vehreschild wrote: > Hi Paul, > > thanks for the review. > > > While I realise that this is not your doing, should we not > > check DECL_LANG_SPECIFIC ()) be

Re: [Ping, Fortran, Patch, PR85510, v2] Fix coarray token in associate not linking

Ping! And the last ping in the series. I have a "bigger" patch in the queue and want the pending ones done beforehand. Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? - Andre On Mon, 22 Jul 2024 16:35:28 +0200 Andre Vehreschild wrote: > Hi all, hi Paul, > > you asked me to h

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

On 8/9/24 4:50 AM, Kewen.Lin wrote: > As PR116266 shows, we miss TARGET_P10_VECTOR to guard those > Power10 related vector instructions as well as their > according built-in functions. This patch is to introduce... LGTM. The only change I would suggest is s/according/associated/ in the sentence

Re: [PATCH] genoutput: Accelerate the place_operands function.

On Wed, Aug 07, 2024 at 03:17:24PM +0100, Richard Sandiford wrote: > Looks like a nice speed-up thanks. > > A couple of general points: > > * Could you try using the more type-safe hash-table.h, instead of hashtab.h? > Similarly inchash.h for the hashing. > > * Although this wasn't always the

[PATCH v5] Target-independent store forwarding avoidance.

This pass detects cases of expensive store forwarding and tries to avoid them by reordering the stores and using suitable bit insertion sequences. For example it can transform this: strbw2, [x1, 1] ldr x0, [x1] # Expensive store forwarding to larger load. To: ldr

Re: [PATCH 1/5] cp: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On 8/9/24 5:26 AM, Alex Coplan wrote: For the testcase added with this patch, we would end up losing the: #pragma GCC unroll 4 and emitting "warning: ignoring loop annotation". That warning comes from tree-cfg.cc:replace_loop_annotate, and means that we failed to process the ANNOTATE_EXPR i

Re: [PATCH 1/5] cp: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On Fri, Aug 09, 2024 at 11:01:22AM -0400, Jason Merrill wrote: > > The CLEANUP_POINT_EXPR gets added by the following call chain: > > > > finish_while_stmt_cond > > -> maybe_convert_cond > > -> condition_conversion > > -> fold_build_cleanup_point_expr > > > > this patch chooses to fix the i

Re: [PATCH] c++: Don't accept multiple enum definitions within template class [PR115806]

On 8/9/24 4:19 AM, Simon Martin wrote: We have been accepting the following invalid code since revision 557831a91df === cut here === template struct S { enum E { a }; enum E { b }; }; S s; === cut here === The problem is that start_enum will set OPAQUE_ENUM_P to true even if it retrieves

Re: [PATCH 1/5] cp: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On 09/08/2024 17:08, Jakub Jelinek wrote: > On Fri, Aug 09, 2024 at 11:01:22AM -0400, Jason Merrill wrote: > > > The CLEANUP_POINT_EXPR gets added by the following call chain: > > > > > > finish_while_stmt_cond > > > -> maybe_convert_cond > > > -> condition_conversion > > > -> fold_build_cle

Re: [RFC/RFA][PATCH v3 06/12] aarch64: Implement new expander for efficient CRC computation

Sorry again for the slow review. :( I only really looked at the unreversed version earlier, on the basis that the comments would apply to both versions. But I've got a couple of comments about the reversed version below: Mariam Arutunian writes: > [...] > diff --git a/gcc/config/aarch64/aarch64

Re: [PATCH] RISC-V: Bugfix for RVV rounding intrinsic ICE in function checker

Hi Jin Ma, Precommit has flagged a large number of ICEs with this patch on vector targets when applied to yesterday's daily bump[1]: https://github.com/ewlu/gcc-precommit-ci/issues/2037#issuecomment-2277469412 Thanks, Patrick [1] https://github.com/gcc-mirror/gcc/commit/77ccfa6ac8d6e4dfefdea

Re: [PATCH 1/5] cp: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On Fri, Aug 09, 2024 at 04:21:14PM +0100, Alex Coplan wrote: > Hmm, good spot, I didn't realise that convert_from_reference could > change the type of the condition like this. > > In that case I suppose the only thing to do is to construct a stack of > ANNOTATE_EXPRs on the way down and re-build t

Re: [PATCH] genoutput: Accelerate the place_operands function.

Xianmiao Qu writes: > On Wed, Aug 07, 2024 at 03:17:24PM +0100, Richard Sandiford wrote: >> Looks like a nice speed-up thanks. >> >> A couple of general points: >> >> * Could you try using the more type-safe hash-table.h, instead of hashtab.h? >> Similarly inchash.h for the hashing. >> >> * A

Re: [PATCH 1/5] cp: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On 09/08/2024 17:34, Jakub Jelinek wrote: > On Fri, Aug 09, 2024 at 04:21:14PM +0100, Alex Coplan wrote: > > Hmm, good spot, I didn't realise that convert_from_reference could > > change the type of the condition like this. > > > > In that case I suppose the only thing to do is to construct a stac

Re: [PATCH v6 3/3] c: Add __lengthof__ operator

On Fri, Aug 09, 2024 at 03:59:19PM GMT, Alejandro Colomar wrote: > This operator is similar to sizeof but can only be applied to an array, > and returns its length (number of elements). > > FUTURE DIRECTIONS: > > - We should make it work with array parameters to functions, >and somehow magic

Re: [PATCH 1/5] cp: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On Fri, Aug 09, 2024 at 04:46:55PM +0100, Alex Coplan wrote: > On 09/08/2024 17:34, Jakub Jelinek wrote: > > On Fri, Aug 09, 2024 at 04:21:14PM +0100, Alex Coplan wrote: > > > Hmm, good spot, I didn't realise that convert_from_reference could > > > change the type of the condition like this. > > >

[PATCH ver 2] rs6000,extend and document built-ins vec_test_lsbb_all_ones and vec_test_lsbb_all_zeros

Gcc maintainers: Version 2, based on discussion additional overloaded instances of the vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros built-ins has been added.  The additional instances are for arguments of vector signed char and vector bool char.  The patch has been tested on Power 10

Re: [PATCH] btf: Protect BTF_KIND_INFO against invalid kind

On 8/7/24 10:19, Will Hawkins wrote: > On Mon, Jul 29, 2024 at 2:14 PM David Faust wrote: >> >> >> On 7/29/24 07:42, Will Hawkins wrote: >>> If the user provides a kind value that is more than 5 bits, the >>> BTF_KIND_INFO macro would emit incorrect values for info (by clobbering >>> values of t

Re: [PATCH] RISC-V: Bugfix for RVV rounding intrinsic ICE in function checker

> Hi Jin Ma,> > Precommit has flagged a large number of ICEs with this patch on vector > targets when applied to yesterday's daily bump[1]: > https://github.com/ewlu/gcc-precommit-ci/issues/2037#issuecomment-2277469412 > > Thanks, > Patrick > > [1] > https://github.com/gcc-mirror/gcc/commit/77cc

Re: [PATCH] c++: Add missing auto_diagnostic_groups

On Fri, Aug 09, 2024 at 11:03:24AM +1000, Nathaniel Shead wrote: > On Thu, Aug 08, 2024 at 03:16:24PM -0400, Marek Polacek wrote: > > On Thu, Aug 08, 2024 at 09:13:05AM +1000, Nathaniel Shead wrote: > > > diff --git a/gcc/cp/error.cc b/gcc/cp/error.cc > > > index 6c22ff55b46..03c19e4a7e4 100644 > >

Re: [PATCH 1/5] cp: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On 09/08/2024 17:56, Jakub Jelinek wrote: > On Fri, Aug 09, 2024 at 04:46:55PM +0100, Alex Coplan wrote: > > On 09/08/2024 17:34, Jakub Jelinek wrote: > > > On Fri, Aug 09, 2024 at 04:21:14PM +0100, Alex Coplan wrote: > > > > Hmm, good spot, I didn't realise that convert_from_reference could > > >

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

On 8/9/24 6:58 AM, Surya Kumari Jangala wrote: I am looking into this failure. Also note that it appears that this change is causing either an infinite loop or severe compile-time regression for Wrestrict. Build a cross for xstormy16-elf. You don't need a full toolchain, just compiler shou

Re: [PATCH v3 01/12] OpenMP: metadirective tree data structures and front-end interfaces

On Sat, Jul 20, 2024 at 02:42:20PM -0600, Sandra Loosemore wrote: > +static tree > +omp_encode_kind_arch_isa_props (tree props) > +{ > + if (!props) > +return NULL_TREE; > + size_t length = 1; > + for (tree p = props; p; p = TREE_CHAIN (p)) > +length += strlen (omp_context_name_list_prop

Re: [PATCH 1/5] cp: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]

On Fri, Aug 09, 2024 at 05:12:00PM +0100, Alex Coplan wrote: > > > I suppose I was just concerned about any other properties of > > > ANNOTATE_EXPRs that might be inherited from the operand (that could be > > > affected by such a change). > > > > > > It looks like TREE_{READONLY,THIS_VOLATILE,SIDE

Re: [PATCH] c++: ICE with NSDMIs and fn arguments [PR116015]

On 8/8/24 1:37 PM, Marek Polacek wrote: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- The problem in this PR is that we ended up with {.rows=(&)->n, .outer_stride=(&)->rows} that is, two PLACEHOLDER_EXPRs for different types on the same level in one { }. That sh

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

On 8/9/24 08:58, Surya Kumari Jangala wrote: I am looking into this failure. Sorry for delay with this email.  I was on vacation. I believe your should reverse the original patch and all the patches you submitted to fix the issues with the original patch. This is a standard procedure in s

Re: [PATCH v3 02/12] OpenMP: middle-end support for metadirectives

On Sat, Jul 20, 2024 at 02:42:21PM -0600, Sandra Loosemore wrote: > --- a/gcc/cgraph.h > +++ b/gcc/cgraph.h > @@ -900,6 +900,7 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cgraph_node : > public symtab_node >ipcp_clone (false), declare_variant_alt (false), >calls_declare_variant_alt (f

Re: [PATCH] c++: inherited CTAD fixes [PR116276]

On 8/8/24 1:00 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- This implements the inherited vs non-inherited guide tiebreaker specified by P2582R1. In order to track inherited-ness of a guide it seems natural to reuse the la

Re: [PATCH] c++: clean up cp_identifier_kind checks

On 8/8/24 11:31 AM, Patrick Palka wrote: The predicates for checking an IDENTIFIER node's cp_identifier_kind currently directly test the three flag bits that encode the kind. This patch instead makes the checks first reconstruct the cp_identifier_kind in its entirety and then compare that. OK.

Re: [PATCH] c++: DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P cleanups

On 8/8/24 11:30 AM, Patrick Palka wrote: DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P templates can only appear as part of a template friend declaration, and in turn get partially instantiated only from tsubst_friend_function or tsubst_friend_class. So rather than having tsubst_template_decl clear the

[PATCH] Use splay-tree-utils.h in tree-ssa-sccvn [PR30920]

This patch is an attempt to gauge opinion on one way of fixing PR30920. The PR points out that the libiberty splay tree implementation does not implement the algorithm described by Sleator and Tarjan and has unclear complexity bounds. (It's also somewhat dangerous in that splay_tree_min and splay

Re: [Ping, Fortran, Patch, PR85510, v2] Fix coarray token in associate not linking

Ok and thanks. On Fri, Aug 9, 2024, 7:33 AM Andre Vehreschild wrote: > Ping! > > And the last ping in the series. I have a "bigger" patch in the queue and > want > the pending ones done beforehand. > > Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? > > - Andre > > On Mon, 22 J

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

On 8/9/24 05:49, Kewen.Lin wrote: Hi, Commit r15-2084 exposes one ICE in LRA. Firstly, before r15-2084 KFmode has 126 bit precision while V1TImode has 128 bit precision, so the subreg (subreg:V1TI (reg:KF 131) 0) is paradoxical_subreg_p, which stops some passes from doing some optimization.

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

Hi! On Fri, Aug 09, 2024 at 05:50:18PM +0800, Kewen.Lin wrote: > As PR116266 shows, we miss TARGET_P10_VECTOR to guard those > Power10 related vector instructions as well as their > according built-in functions. This patch is to introduce > TARGET_P10_VECTOR which is actually TARGET_POWER10 && >

Re: [RFC/RFA][PATCH v3 06/12] aarch64: Implement new expander for efficient CRC computation

Richard Sandiford writes: > [...] > /* Perform a shift right by CRC_SIZE as an extraction of lane 1. */ > machine_mode crc_vmode = aarch64_vq_mode (crc_mode).require (); > a0 = (crc_size > data_size ? gen_reg_rtx (crc_mode) : operands[0]); > emit_insn (gen_aarch64_get_lane (crc_vmode, a0,

Re: [PATCH v2] Hard register constraints

Am 05.08.24 um 12:28 schrieb Stefan Schulze Frielinghaus: This is a follow-up of https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654013.html Hi Stefan, as an addition, maybe a built-in macro is useful that tells the target code whether the feature is available. Similar to __GXX_CONSTEXPR_

Re: [PATCH] c++: inherited CTAD fixes [PR116276]

On Fri, 9 Aug 2024, Jason Merrill wrote: > On 8/8/24 1:00 PM, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > > look OK for trunk/14? > > > > -- >8 -- > > > > This implements the inherited vs non-inherited guide tiebreaker > > specified by P2582R1. In ord

[to-be-committed][RISC-V][PR target/116283] Fix split code for recent Zbs improvements with masked bit positions

So Patrick's fuzzer found an interesting little buglet in the Zbs improvements I added a couple months back. Specifically when we have masked bit position for a Zbs instruction. If the mask has extraneous bits set we'll generate an unrecognizable insn due to an invalid constant. More concre

Re: [PATCH] c++: inherited CTAD fixes [PR116276]

On Fri, 9 Aug 2024, Patrick Palka wrote: > On Fri, 9 Aug 2024, Jason Merrill wrote: > > > On 8/8/24 1:00 PM, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > > > look OK for trunk/14? > > > > > > -- >8 -- > > > > > > This implements the inherited vs non-

[PATCH] c++: Implement C++23 P2718R0 - Wording for P2644R1 Fix for Range-based for Loop [PR107637]

Hi! The following patch implements the C++23 P2718R0 paper - Wording for P2644R1 Fix for Range-based for Loop. As all the temporaries from __for_range initialization should have life extended until the end of __for_range scope, this patch disables (for C++23 and later only and if !processing_templ

Re: [PATCH] c++: inherited CTAD fixes [PR116276]

On 8/9/24 2:32 PM, Patrick Palka wrote: On Fri, 9 Aug 2024, Patrick Palka wrote: On Fri, 9 Aug 2024, Jason Merrill wrote: On 8/8/24 1:00 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- This implements the inherited vs non

Re: [PATCH] Use splay-tree-utils.h in tree-ssa-sccvn [PR30920]

> Am 09.08.2024 um 19:19 schrieb Richard Sandiford : > > This patch is an attempt to gauge opinion on one way of fixing PR30920. > > The PR points out that the libiberty splay tree implementation does > not implement the algorithm described by Sleator and Tarjan and has > unclear complexity b

[COMMITTED 1/2] PR tree-optimization/114855 - Limit equivalency processing in rangers cache.

Range_from_dom () fills the cache as it search so that subsequent searches do not have to follow the full dominator chain and can pick up values from the cache. This makes it self limiting from a cost point of view.   Normally.  The exception was during equivalence processing when the cache doe

[COMMITTED 2/2] PR tree-optimization/114855 - Adjust rangers recomputation depth based on the number of BBs.

The other place a lot of time is being spent is in the recomputation section. We have a depth limit parameter (ranger-recompuation-depth) which defaults to 5, and specifies the number of statements back we will look to recompute.. this allows us to recompute some relatively complicated things.

Re: [PATCH] tree-optimization/116166 - forward jump-threading going wild

On 8/7/24 03:13, Richard Biener wrote: On Tue, 6 Aug 2024, Andrew MacLeod wrote: On 8/6/24 09:12, Richard Biener wrote: Currently the forward threader isn't limited as to the search space it explores and with it now using path-ranger for simplifying conditions it runs into it became pretty s

Re: [PATCH] c++: inherited CTAD fixes [PR116276]

On Fri, 9 Aug 2024, Jason Merrill wrote: > On 8/9/24 2:32 PM, Patrick Palka wrote: > > On Fri, 9 Aug 2024, Patrick Palka wrote: > > > > > On Fri, 9 Aug 2024, Jason Merrill wrote: > > > > > > > On 8/8/24 1:00 PM, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, do

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

> On 9 Aug 2024, at 19:02, Vladimir Makarov wrote: > > External email: Use caution opening links or attachments > > > On 8/9/24 08:58, Surya Kumari Jangala wrote: >> I am looking into this failure. >> > Sorry for delay with this email. I was on vacation. > > I believe your should reverse t

Re: [PATCH] tree-optimization/116166 - forward jump-threading going wild

On 8/6/24 7:12 AM, Richard Biener wrote: Currently the forward threader isn't limited as to the search space it explores and with it now using path-ranger for simplifying conditions it runs into it became pretty slow for degenerate cases like compiling insn-emit.cc for RISC-V esp. when compili

Re: [PATCH] c++: ICE with NSDMIs and fn arguments [PR116015]

On Fri, Aug 09, 2024 at 12:58:34PM -0400, Jason Merrill wrote: > On 8/8/24 1:37 PM, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > The problem in this PR is that we ended up with > > > >{.rows=(&)->n, > > .outer_stride=(&)->rows}

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

On 8/9/24 12:54 PM, Segher Boessenkool wrote: >> --- a/gcc/config/rs6000/altivec.md >> +++ b/gcc/config/rs6000/altivec.md >> @@ -623,7 +623,7 @@ (define_insn "altivec_eqv1ti" >>[(set (match_operand:V1TI 0 "altivec_register_operand" "=v") >> (eq:V1TI (match_operand:V1TI 1 "altivec_register

  1   2   >