[r15-3052 Regression] FAIL: gfortran.dg/sizeof_6.f90 -O1 execution test on Linux/x86_64

On Linux/x86_64, c7b76a076cb2c6ded7ae208464019b04cb0531a2 is the first bad commit commit c7b76a076cb2c6ded7ae208464019b04cb0531a2 Author: Andrew Pinski Date: Mon Aug 19 08:06:36 2024 -0700 match: Reject non-ssa name/min invariants in gimple_extract [PR116412] caused FAIL: gfortran.dg/siz

[PATCH v3] RISC-V: Enable -gvariable-location-views by default

This affects only the RISC-V targets, where the compiler options -gvariable-location-views and consequently also -ginline-points are disabled by default, which is unexpected and disables some useful features of the generated debug info. Due to a bug in the gas assembler the .loc statement is not u

Re: [PATCH] Do not emit a redundant DW_TAG_lexical_block for inlined subroutines

On Tue, 20 Aug 2024, Bernd Edlinger wrote: > On 8/20/24 13:00, Richard Biener wrote: > > On Fri, Aug 16, 2024 at 12:49 PM Bernd Edlinger > > wrote: > >> > >> While this already works correctly for the case when an inlined > >> subroutine contains only one subrange, a redundant DW_TAG_lexical_bloc

[PATCH] rs6000: allow split vsx_stxvd2x4_le_const after RA[pr116030]

Hi, Previous, vsx_stxvd2x4_le_const_ is introduced for 'split1' pass, so it is guarded by "can_create_pseudo_p ()". While, it would be possible to match the pattern of this insn during/after RA, so this insn could be updated to make it work for split pass after RA. Bootstrap®test pass on ppc64{,l

Re: [PATCH 1/2] SVE intrinsics: Fold constant operands for svdiv

> On 19 Aug 2024, at 17:03, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Kyrylo Tkachov mailto:ktkac...@nvidia.com>> writes: >> Hi Richard, >> >>> On 19 Aug 2024, at 14:57, Richard Sandiford >>> wrote: >>> >>> External email: Use caution open

Re: [PATCH] rs6000: allow split vsx_stxvd2x4_le_const after RA[pr116030]

Jiufu Guo writes: > Hi, > > Previous, vsx_stxvd2x4_le_const_ is introduced for 'split1' pass, > so it is guarded by "can_create_pseudo_p ()". > While, it would be possible to match the pattern of this insn during/after > RA, so this insn could be updated to make it work for split pass after RA. >

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

Hi Jerry, thank you for the review. Committed as gcc-15-3062-g515730fd65a Thanks again, Andre On Tue, 20 Aug 2024 09:16:50 -0700 Jerry D wrote: > On 8/20/24 5:35 AM, Andre Vehreschild wrote: > > Hi all, > > > > pinging this patch. > > > > Regtests ok on x86_64-pc-linux-gnu / Fedora 39.

Re: [PATCH] rs6000: allow split vsx_stxvd2x4_le_const after RA[pr116030]

Hi, Sam James writes: > Jiufu Guo writes: > >> Hi, >> >> Previous, vsx_stxvd2x4_le_const_ is introduced for 'split1' pass, >> so it is guarded by "can_create_pseudo_p ()". >> While, it would be possible to match the pattern of this insn during/after >> RA, so this insn could be updated to mak

Re: [RFC] Generalize formation of lane-reducing ops in loop reduction

>> >> >> 1. Background >> >> >> >> For loop reduction of accumulating result of a widening operation, the >> >> preferred pattern is lane-reducing operation, if supported by target. >> >> Because >> >> this kind of operation need not preserve intermediate results of widening >> >> operation, and o

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

On Wed, 21 Aug 2024, Robin Dapp wrote: > > > > When predicating a load we implicitly assume that the else value is > > > > zero. In order to formalize this this patch queries the target for > > > > its supported else operand and uses that for the maskload call. > > > > Subsequently, if the else o

[pushed] c++, coroutines: Check for malformed functions before splitting.

tested on x86_64-darwin, powerpc64-linux and against cppcoro and folly coroutines tests, pushed to trunk as obvious, thanks, Iain --- 8< --- This performs the same basic check that is done by finish_function to catch cases where the function is so badly malformed that we do not have a consistent

[PATCH] c++, coroutines: Tidy up awaiter variable checks.

Tested on x86_64-darwin, powerpc64le-linux, and against cppcoro and folly coroutines testsuites, OK for trunk? thanks Iain --- 8< --- When we build an await expression, we might need to materialise the awaiter if it is a prvalue. This re-implements this using core APIs instead of local code. gc

Re: [PATCH 0/7] v3 of libdiagnostics

On Wed, Aug 21, 2024 at 2:01 AM David Malcolm wrote: > > On Tue, 2024-08-20 at 11:49 +0200, Richard Biener wrote: > > On Thu, Aug 15, 2024 at 8:13 PM David Malcolm > > wrote: > > > > > > Here's v3 of my patch kit for "libdiagnostics", which makes GCC's > > > diagnostics subsystem available as a s

[PATCH V2] add rlwinm pattern for DImode for constant building

Hi, 'rlwinm' pattern is already well used for SImode. As this instruction can touch the whole 64bit register, so some constants in DImode can be built via 'lis/li+rlwinm'. To achieve this, a new pattern for 'rlwinm' is added, and use this pattern if a constant is able to be built by 'lis/li; rlw

Re: [PATCH v3 5/7] OpenMP: common C/C++ testcases for dispatch + adjust_args

Here is an updated version following Tobias's review on the ME patch. The differences compared to the previous version are: * updated DejaGnu patterns * added testcase dispatch-8.c -- PA commit 533f2693680f109837f03cda2e123b155bbb5c60 Author: Paul-Antoine Arras Date: Fri May 24 19:04:35 2024 +0

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

On Tue, Aug 20, 2024 at 3:41 PM Qing Zhao wrote: > > > > > On Aug 20, 2024, at 05:58, Richard Biener > > wrote: > > > > On Tue, Aug 13, 2024 at 5:34 PM Qing Zhao wrote: > >> > >> With the addition of the 'counted_by' attribute and its wide roll-out > >> within the Linux kernel, a use case has b

Re: [PATCH] Do not emit a redundant DW_TAG_lexical_block for inlined subroutines

On Wed, 21 Aug 2024, Richard Biener wrote: > On Tue, 20 Aug 2024, Bernd Edlinger wrote: > > > On 8/20/24 13:00, Richard Biener wrote: > > > On Fri, Aug 16, 2024 at 12:49 PM Bernd Edlinger > > > wrote: > > >> > > >> While this already works correctly for the case when an inlined > > >> subroutine

Re: [PATCH v3 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

Here is an updated version following Tobias's review on the ME patch. The main differences compared to the previous version are: * Added support for !$OMP END DISPATCH * Added testcase dispatch-9.f90 * Updated DejaGnu patterns -- PA commit d427c071326c7bf6ccf7ccbc06d6d1cbbb29e73a Author: Paul-Anto

[wwwdocs v2] gcc-15: Mention c++ header dependency changes () in porting_to.html

Hi, this is the second version of my patch. See version 1 here: https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659584.html Changes made: - Removed plural when referring to the single changed header. From the two versions of the text I considered I chose the one with less changes as

Re: [PATCH] Align ix86_{move_max,store_max} with vectorizer.

On Wed, Aug 21, 2024 at 7:40 AM liuhongt wrote: > > When none of mprefer-vector-width, avx256_optimal/avx128_optimal, > avx256_store_by_pieces/avx512_store_by_pieces is specified, GCC will > set ix86_{move_max,store_max} as max available vector length except > for AVX part. > > if (T

Re: [wwwdocs v2] gcc-15: Mention c++ header dependency changes () in porting_to.html

On Wed, 21 Aug 2024 at 09:48, Filip Kastl wrote: > > Hi, > > this is the second version of my patch. See version 1 here: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659584.html > > Changes made: > - Removed plural when referring to the single changed header. From the two > versio

[committed] libstdc++: Fix std::variant to reject array types [PR116381]

Tested x86_64-linux. Pushed to trunk. Probably worth backporting too. It could potentially cause new errors for people using arrays in std::variant, but that's forbidden by the standard. -- >8 -- libstdc++-v3/ChangeLog: PR libstdc++/116381 * include/std/variant (variant): Fix co

Re: [PATCH] optabs-query: Guard smallest_int_mode_for_size [PR115495].

On Wed, Aug 21, 2024 at 8:37 AM Robin Dapp wrote: > > Hi, > > in get_best_extraction_insn we use smallest_int_mode_for_size with > struct_bits as size argument. In PR115495 struct_bits = 256 and we > don't have a mode for that. This patch just bails for such cases. > > This does not happen on th

Re: [committed] libstdc++: Fix std::variant to reject array types [PR116381]

On Wed, 21 Aug 2024 at 09:55, Jonathan Wakely wrote: > > Tested x86_64-linux. Pushed to trunk. > > Probably worth backporting too. It could potentially cause new errors > for people using arrays in std::variant, but that's forbidden by the > standard. Notably, both libc++ and MSVC STL reject array

[PATCH] libstdc++: Simplify C++20 implementation of std::variant

Tested x86_64-linux. This should improve compile times for C++20 and up. I need to test this with Clang, but then I plan to push it if all goes well. -- >8 -- For C++20 the __detail::__variant::_Uninitialized primary template can be used for all types, because _Variant_union can have a non-triv

Re: [committed] libstdc++: Fix std::variant to reject array types [PR116381]

On Wed, Aug 21, 2024 at 1:56 AM Jonathan Wakely wrote: > > Tested x86_64-linux. Pushed to trunk. > > Probably worth backporting too. It could potentially cause new errors > for people using arrays in std::variant, but that's forbidden by the > standard. It might be worth mentioning in porting_to

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

On Sun, 11 Aug 2024, Robin Dapp wrote: > This patch adds else-operand handling to the internal functions. LGTM. > gcc/ChangeLog: > > * internal-fn.cc (add_mask_and_len_args): Rename... > (add_mask_else_and_len_args): ...to this and add else handling. > (expand_partial_load_opt

Re: [committed] libstdc++: Fix std::variant to reject array types [PR116381]

On Wed, 21 Aug 2024 at 10:03, Andrew Pinski wrote: > > On Wed, Aug 21, 2024 at 1:56 AM Jonathan Wakely wrote: > > > > Tested x86_64-linux. Pushed to trunk. > > > > Probably worth backporting too. It could potentially cause new errors > > for people using arrays in std::variant, but that's forbidd

Re: [PATCH] Align ix86_{move_max,store_max} with vectorizer.

On Wed, Aug 21, 2024 at 4:49 PM Richard Biener wrote: > > On Wed, Aug 21, 2024 at 7:40 AM liuhongt wrote: > > > > When none of mprefer-vector-width, avx256_optimal/avx128_optimal, > > avx256_store_by_pieces/avx512_store_by_pieces is specified, GCC will > > set ix86_{move_max,store_max} as max ava

Re: [Fortran, Patch, PR86468, v1] Fix propagation of corank to array components in derived types.

Hi Harald, thanks for the review. I have changed the style of the code. Interestingly did the contrib/check_GNU_style.(py|sh) not complain on the old style nor on the new style. I tend to just trust clang-format to do a reproducible job and stick with that. Committed as: gcc-15-3066-g723b30bee4e

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

On Sun, 11 Aug 2024, Robin Dapp wrote: > This patch adds an else operand to vectorized masked load calls. > The current implementation adds else-value arguments to the respective > target-querying functions that is used to supply the vectorizer with the > proper else value. > > Right now, the onl

Re: [PATCH] sra: Avoid risking x87 magling binary representation of a replacement (PR 58416)

On Mon, 19 Aug 2024, Martin Jambor wrote: > Hi, > > PR 58416 shows that storing non-floating point data to floating point > scalar registers can lead to miscompilations when the data is > normalized or otherwise processed upon loading to a register. To > avoid that risk, this patch detects situa

Re: [PATCH] Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook

On Tue, Aug 20, 2024 at 3:24 PM H.J. Lu wrote: > > On Tue, Aug 20, 2024 at 2:03 AM Richard Biener > wrote: > > > > On Wed, Aug 14, 2024 at 3:15 PM H.J. Lu wrote: > > > > > > The new hook allows the linker plugin to distinguish calls to > > > claim_file_handler that know the object is being used

Re: [PATCH] MATCH: add abs support for half float

Hi Richard, > On 20 Aug 2024, at 6:09 pm, Richard Biener wrote: > > External email: Use caution opening links or attachments > > > On Fri, Aug 9, 2024 at 2:39 AM Kugan Vivekanandarajah > wrote: >> >> Thanks for the comments. >> >>> On 2 Aug 2024, at 8:36 pm, Richard Biener >>> wrote: >>>

Re: [PATCH] ifcvt: Fix force_operand ICE due to noce_convert_multiple_sets [PR116353]

On Tue, Aug 13, 2024 at 10:48 PM Jeff Law wrote: > > > > On 8/13/24 5:57 AM, Manolis Tsamis wrote: > > Now that more operations are allowed for noce_convert_multiple_sets, we > > need to > > check noce_can_force_operand on the sequence before calling > > try_emit_cmove_seq. > > Otherwise an inap

[Fortran, Patch, PR86468, v1] Follow up: Remove obsolete VIEW_CONVERT

Hi all, attached small patch removes a VIEW_CONVERT that I erroneously inserted during patching pr110033. PR86468 fixes the (co-)rank computation and therefore this VIEW_CONVERT is IMO obsolete. I think it may cause hard to find runtime bugs in the future and therefore like to remove it. Regtests

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

> > > Why? I don't think the vectorizer relies on a particular else > > > value? I'd say it would be appropriate for if-conversion to > > > use "ANY" and for the vectorizer to then pick a supported > > > version and/or enforce the else value it needs via a blend? > > > > In PR115336 we have some

Ping^2: C++/ME patch ping

Hi, Pinging these patches again: - https://inbox.sourceware.org/20240807131613.526335-1-ar...@aarsen.me/ - https://inbox.sourceware.org/20240802211503.3992610-2-ar...@aarsen.me/ Thanks in advance, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature

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

On Wed, 21 Aug 2024, Robin Dapp wrote: > > > > Why? I don't think the vectorizer relies on a particular else > > > > value? I'd say it would be appropriate for if-conversion to > > > > use "ANY" and for the vectorizer to then pick a supported > > > > version and/or enforce the else value it need

Re: [PATCH] libstdc++: Check ios::uppercase for ios::fixed floating-point output [PR114862]

This is still pending a decision by LEWG, but I've pushed it to trunk anyway. We can always revert it before GCC 15 is released if the committee decides against it, but this way we might get user feedback on it. On Thu, 1 Aug 2024 at 22:41, Jonathan Wakely wrote: > > Tested x86_64-linux. > > --

RE: Re-compute TYPE_MODE and DECL_MODE while streaming in for accelerator

> -Original Message- > From: Richard Biener > Sent: Tuesday, August 20, 2024 10:36 AM > To: Richard Sandiford > Cc: Prathamesh Kulkarni ; Thomas Schwinge > ; gcc-patches@gcc.gnu.org > Subject: Re: Re-compute TYPE_MODE and DECL_MODE while streaming in for > accelerator > > External emai

Re: [RFC] Support single lane SLP early break

On Tue, 20 Aug 2024, Tamar Christina wrote: > Hi, > > I've been working on a prototype of moving early break to SLP. > > As we've discussed on IRC I've decided to first try adding the gconds as roots > and start SLP discovery using them as roots. > > This works great and doesn't require any cha

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

> > > > _Bool iftmp.0_113; > > > > _Bool iftmp.0_114; > > > > iftmp.0_113 = .MASK_LOAD (_170, 8B, _169, _171(D)); > > > > iftmp.0_114 = _47 | iftmp.0_113; > > _BoolD.2746 _47; > > iftmp.0_114 = _47 ? 1 : iftmp.0_113; > > which is folded into > > iftmp.0_114 = _47 | iftmp.0_113; > >

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

On Tue, Aug 20, 2024 at 3:35 PM Juergen Christ wrote: > > Am Tue, Aug 20, 2024 at 02:51:02PM +0200 schrieb Richard Biener: > > On Tue, Aug 20, 2024 at 11:16 AM Juergen Christ > > wrote: > > > > > > Am Tue, Aug 20, 2024 at 10:15:22AM +0200 schrieb Richard Biener: > > > > On Fri, Aug 9, 2024 at 2:

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

On Wed, 21 Aug 2024, Robin Dapp wrote: > > > > > _Bool iftmp.0_113; > > > > > _Bool iftmp.0_114; > > > > > iftmp.0_113 = .MASK_LOAD (_170, 8B, _169, _171(D)); > > > > > iftmp.0_114 = _47 | iftmp.0_113; > > > > _BoolD.2746 _47; > > > iftmp.0_114 = _47 ? 1 : iftmp.0_113; > > > which is

Re: [PATCH] Do not emit a redundant DW_TAG_lexical_block for inlined subroutines

On 8/21/24 10:45, Richard Biener wrote: > On Wed, 21 Aug 2024, Richard Biener wrote: > >> On Tue, 20 Aug 2024, Bernd Edlinger wrote: >> >>> On 8/20/24 13:00, Richard Biener wrote: On Fri, Aug 16, 2024 at 12:49 PM Bernd Edlinger wrote: > > While this already works correctly for t

RE: Re-compute TYPE_MODE and DECL_MODE while streaming in for accelerator

On Wed, 21 Aug 2024, Prathamesh Kulkarni wrote: > > > > -Original Message- > > From: Richard Biener > > Sent: Tuesday, August 20, 2024 10:36 AM > > To: Richard Sandiford > > Cc: Prathamesh Kulkarni ; Thomas Schwinge > > ; gcc-patches@gcc.gnu.org > > Subject: Re: Re-compute TYPE_MODE an

Re: [PATCH] Do not emit a redundant DW_TAG_lexical_block for inlined subroutines

On Wed, 21 Aug 2024, Bernd Edlinger wrote: > On 8/21/24 10:45, Richard Biener wrote: > > On Wed, 21 Aug 2024, Richard Biener wrote: > > > >> On Tue, 20 Aug 2024, Bernd Edlinger wrote: > >> > >>> On 8/20/24 13:00, Richard Biener wrote: > On Fri, Aug 16, 2024 at 12:49 PM Bernd Edlinger >

Re: [Ping, Patch, Fortran, 77871, v1] Allow for class typed coarray parameter as dummy [PR77871]

Hi all, pinging this patch for the first time. Rebased and regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? - Andre On Thu, 15 Aug 2024 14:39:25 +0200 Andre Vehreschild wrote: > Hi all, > > attached patch fixes another regression on coarrays. This time for class typed > coarr

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

> And we fail to fold vect_patt_384.36_436 | { 1, ... } to { 1, ... }? > Or is the issue that vector masks contain padding and with > non-zero masking we'd have garbage in the padding and that leaks > here? That is, _47 ? 1 : iftmp.0_113 -> _47 | iftmp.0_113 assumes > there's exactly one bit in a

[PATCH] tree-optimization/116380 - bogus SSA update with loop distribution

When updating LC PHIs after copying loops we have to handle defs defined outside of the loop appropriately (by not setting them to NULL ...). This mimics how we handle this in the SSA updating code of the vectorizer. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard.

Re: [PATCH] Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook

On Wed, Aug 21, 2024 at 2:38 AM Richard Biener wrote: > > On Tue, Aug 20, 2024 at 3:24 PM H.J. Lu wrote: > > > > On Tue, Aug 20, 2024 at 2:03 AM Richard Biener > > wrote: > > > > > > On Wed, Aug 14, 2024 at 3:15 PM H.J. Lu wrote: > > > > > > > > The new hook allows the linker plugin to distingu

Re: [PING] [PATCH v2] Support if conversion for switches

On Tue, Aug 13, 2024 at 7:34 PM Andi Kleen wrote: > > Andi Kleen writes: > > I wanted to ping this patch. I believe Richard ok'ed most of it earlier > but need an ok for the changes resulting from his review too > (but they were mostly only test suite and comment fixes > apart from some minor twe

Re: [PATCH 1/2] Makefile.tpl: drop leftover intermodule cruft

On Thu, Aug 15, 2024 at 12:14 AM Sam James wrote: > > intermodule supported was dropped in r0-103106-gde6ba7aee152a0 with some > remaining bits for Fortran removed in r14-1696-gecc96eb5d2a0e5. OK > Remove some small leftovers. > > * Makefile.in: Regenerate. > * Makefile.tpl (STAG

Re: [PATCH 1/2] SVE intrinsics: Fold constant operands for svdiv

Jennifer Schmitz writes: > thank you for the feedback. I would like to summarize what I understand from > your suggestions before I start revising to make sure we are on the same page: > > 1. The new setup for constant folding of SVE intrinsics for binary operations > where both operands are con

[patch] libgomp: Add interop types and routines to OpenMP's headers and module

This patch adds 'interop' to C/C++'s omp.h and Fortran's omp_lib.h and omp_lib module. The implementation should match OpenMP 5.1 (which added interop) and also TR13; the Fortran routine support is new in TR13. It also adds 'hsa' as foreign object enum/paramter, which is currently being added

[PATCH 3/2] libstdc++: Optimize std::projected

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? I'm not sure if the current specification of 'projected' strictly speaking allows for this optimization, but it seems like a natural one that should be allowed. -- >8 -- Algorithms that are generalized to take projections usually defaul

[PATCH] rs6000: Fix PTImode handling in power8 swap optimization pass [PR116415]

Our power8 swap optimization pass has some special handling for optimizing swaps of TImode variables. The test case reported in bugzilla uses a call to __atomic_compare_exchange, which introduces a variable of PTImode and that does not get the same treatment as TImode leading to wrong code genera

Re: [PATCH 3/2] libstdc++: Optimize std::projected

On Wed, 21 Aug 2024 at 13:58, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? I'm not > sure if the current specification of 'projected' strictly speaking > allows for this optimization, but it seems like a natural one that > should be allowed. Yeah, I can't s

Re: [PATCH] Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook

On Wed, Aug 21, 2024 at 2:27 PM H.J. Lu wrote: > > On Wed, Aug 21, 2024 at 2:38 AM Richard Biener > wrote: > > > > On Tue, Aug 20, 2024 at 3:24 PM H.J. Lu wrote: > > > > > > On Tue, Aug 20, 2024 at 2:03 AM Richard Biener > > > wrote: > > > > > > > > On Wed, Aug 14, 2024 at 3:15 PM H.J. Lu wrot

Re: [PATCH] testsuite: Add -fwrapv to signbit-5.c

On 2024-08-20 14:37, Tamar Christina wrote: -Original Message- From: Richard Biener Sent: Tuesday, August 20, 2024 12:33 PM To: Torbjorn SVENSSON Cc: Jeff Law ; gcc-patches@gcc.gnu.org; Richard Earnshaw ; quic_apin...@quicinc.com; yvan.r...@foss.st.com; Tamar Christina Subject: Re:

[PATCH] tree-optimization/116406 - ICE with int<->float punning prevention

The following does away with the idea to use non-symmetrical testing of mode_can_transfer_bits in hash-table equality testing. It isn't feasible to always control query order to maintain consistency. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/116406

Re: [PATCH 1/2] libstdc++: Implement P2609R3 changes to the indirect invocability concepts

On Wed, 21 Aug 2024 at 01:40, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps > 14? > > -- >8 -- > > This implements the changes of this C++23 paper as a DR against C++20. It's a little unfortunate that we can't bump the __cpp_lib_ranges macro for C+

[PATCH v1 1/2] RISC-V: Add testcases for unsigned vector .SAT_TRUNC form 2

From: Pan Li This patch would like to add test cases for the unsigned vector .SAT_TRUNC form 2. Aka: Form 2: #define DEF_VEC_SAT_U_TRUNC_FMT_2(NT, WT) \ void __attribute__((noinline))\ vec_sat_u_trunc_##NT##_##WT##_fmt_2

[PATCH v1 2/2] RISC-V: Add testcases for unsigned vector .SAT_TRUNC form 3

From: Pan Li This patch would like to add test cases for the unsigned vector .SAT_TRUNC form 3. Aka: Form 3: #define DEF_VEC_SAT_U_TRUNC_FMT_3(NT, WT) \ void __attribute__((noinline))\ vec_sat_u_trunc_##NT##_##WT##_fmt_3

Re: [PATCH 2/2] libstdc++: Implement P2997R1 changes to the indirect invocability concepts

On Wed, 21 Aug 2024 at 01:40, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps > 14? > > -- >8 -- > > This implements the changes of this C++26 paper as a DR against C++20. > > libstdc++-v3/ChangeLog: > > * include/bits/iterator_concepts.h (in

Re: [PATCH] Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook

On Wed, Aug 21, 2024 at 6:23 AM Richard Biener wrote: > > On Wed, Aug 21, 2024 at 2:27 PM H.J. Lu wrote: > > > > On Wed, Aug 21, 2024 at 2:38 AM Richard Biener > > wrote: > > > > > > On Tue, Aug 20, 2024 at 3:24 PM H.J. Lu wrote: > > > > > > > > On Tue, Aug 20, 2024 at 2:03 AM Richard Biener >

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

Mariam Arutunian writes: > This patch introduces two new expanders for the aarch64 backend, > dedicated to generate optimized code for CRC computations. > The new expanders are designed to leverage specific hardware capabilities > to achieve faster CRC calculations, > particularly using the crc32,

.

> On Aug 21, 2024, at 04:44, Richard Biener wrote: > > On Tue, Aug 20, 2024 at 3:41 PM Qing Zhao wrote: >> >> >> >>> On Aug 20, 2024, at 05:58, Richard Biener >>> wrote: >>> >>> On Tue, Aug 13, 2024 at 5:34 PM Qing Zhao wrote: With the addition of the 'counted_by' attribute a

Re: [PATCH] PR target/116365: Add user-friendly arguments to --param aarch64-autovec-preference=N

Kyrylo Tkachov writes: >> On 20 Aug 2024, at 19:11, Richard Sandiford >> wrot>> Jennifer Schmitz writes: >>> The param aarch64-autovec-preference=N is a useful tool for testing >>> auto-vectorisation in GCC as it allows the user to force a particular >>> strategy. So far, N could be an numerica

Re: [PATCH v2] aarch64: Implement popcountti2 pattern [PR113042]

Andrew Pinski writes: > When CSSC is not enabled, 128bit popcount can be implemented > just via the vector (v16qi) cnt instruction followed by a reduction, > like how the 64bit one is currently implemented instead of > splitting into 2 64bit popcount. > > Changes since v1: > * v2: Make operand 0 b

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

(Resend since the previous one has no subject). > On Aug 21, 2024, at 04:44, Richard Biener wrote: > > On Tue, Aug 20, 2024 at 3:41 PM Qing Zhao wrote: >> >> >> >>> On Aug 20, 2024, at 05:58, Richard Biener >>> wrote: >>> >>> On Tue, Aug 13, 2024 at 5:34 PM Qing Zhao wrote: Wi

Re: [PATCH] optabs-query: Guard smallest_int_mode_for_size [PR115495].

Richard Biener writes: > On Wed, Aug 21, 2024 at 8:37 AM Robin Dapp wrote: >> >> Hi, >> >> in get_best_extraction_insn we use smallest_int_mode_for_size with >> struct_bits as size argument. In PR115495 struct_bits = 256 and we >> don't have a mode for that. This patch just bails for such cases

[PATCH v3] Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook

This hook allows the BFD linker plugin to distinguish calls to claim_file_handler that know the object is being used by the linker (from ldmain.c:add_archive_element), from calls that don't know it's being used by the linker (from elf_link_is_defined_archive_symbol); in the latter case, the plugin

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

Am Mittwoch, dem 21.08.2024 um 14:12 + schrieb Qing Zhao: ... > > > > > > + if (__builtin_get_counted_by (__p->FAM)) \ > > > + *(__builtin_get_counted_by(__p->FAM)) = COUNT; \ > > > > > > How to improve it? (Thanks a lot for your suggestion). > > > > There's lack of syntactic guarantee t

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

Am Mittwoch, dem 21.08.2024 um 16:34 +0200 schrieb Martin Uecker: > Am Mittwoch, dem 21.08.2024 um 14:12 + schrieb Qing Zhao: > > > > > Yes, I do feel that the approach __builtin_get_counted_by is not very good. > > Maybe it’s better to provide > > A. __builtin_set_counted_by > > or > > B.

Re: [wwwdocs v2] gcc-15: Mention c++ header dependency changes () in porting_to.html

On Wed 2024-08-21 09:50:39, Jonathan Wakely wrote: > On Wed, 21 Aug 2024 at 09:48, Filip Kastl wrote: > > > > Hi, > > > > this is the second version of my patch. See version 1 here: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659584.html > > > > Changes made: > > - Removed plura

[PATCH v2] combine.cc (make_more_copies): Copy attributes from the original pseudo, PR115883

The only thing that's changed with the patch in v2 since the first version (pinged once) is the commit message. CC to the nexts-of-kin as a heads-up. Regtested cross to cris-elf and native x86_64-linux-gnu at r15-3043-g64028d626a50. The gcc.dg/guality/pr54200.c magically being fixed was also not

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

> On Aug 21, 2024, at 10:34, Martin Uecker wrote: > > Am Mittwoch, dem 21.08.2024 um 14:12 + schrieb Qing Zhao: > > ... >> >>> + if (__builtin_get_counted_by (__p->FAM)) \ + *(__builtin_get_counted_by(__p->FAM)) = COUNT; \ How to improve it? (Thanks a lot for your

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

> On Aug 21, 2024, at 10:45, Martin Uecker wrote: > > Am Mittwoch, dem 21.08.2024 um 16:34 +0200 schrieb Martin Uecker: >> Am Mittwoch, dem 21.08.2024 um 14:12 + schrieb Qing Zhao: >> >>> >>> Yes, I do feel that the approach __builtin_get_counted_by is not very good. >>> Maybe it’s bette

Re: [PATCH v1 1/2] RISC-V: Add testcases for unsigned vector .SAT_TRUNC form 2

LGTM. -- Regards Robin

Re: [PATCH v1 2/2] RISC-V: Add testcases for unsigned vector .SAT_TRUNC form 3

LGTM. -- Regards Robin

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

Am Mittwoch, dem 21.08.2024 um 15:24 + schrieb Qing Zhao: > > > > But if we changed it to return a void pointer, we could make this > > a compile-time check: > > > > auto ret = __builtin_get_counted_by(__p->FAM); > > > > _Generic(ret, void*: (void)0, default: *ret = COUNT); > > Is there an

Re: [PATCH] c, v2: Add support for unsequenced and reproducible attributes

On Thu, 1 Aug 2024, Jakub Jelinek wrote: > +Unsequenced functions without pointer or reference arguments are similar > +to functions with the @code{const} attribute, except that @code{const} > +attribute also requires finitness. So, both functions with @code{const} s/finitness/finiteness/ (in al

[PATCH] arm: Always use vmov.f64 instead of vmov.f32 with MVE

With MVE, vmov.f64 is always supported (no need for +fp.dp extension). This patch updates two patterns: - in movdi_vfp, we incorrectly checked TARGET_VFP_SINGLE || TARGET_HAVE_MVE instead of TARGET_VFP_SINGLE && !TARGET_HAVE_MVE, and didn't take into account these two possibilities when comp

Re: [PATCH] testuite: Accept vmov.f64

On Wed, 14 Aug 2024 at 22:04, Torbjörn SVENSSON wrote: > > Ok for trunk and releases/gcc-14? > > -- > > On Cortex-M55 with fpv5-d16, the vmov.f64 instruction is used. Hi Torbjorn, Thanks for the patch: after looking further I realized that we can always generate vmov.f64 with MVE, so I propose t

[PATCH v2] tree-optimization/116024 - match.pd: add 4 int-compare simplifications

Hi, sending a v2 of https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659851.html after changing variable types in all new testcases from standard to fixed-width. Could anyone please assist with reviewing and/or pushing to trunk/14 since I don't have commit access? Many thanks, Artemiy

Re: [Fortran, Patch, PR86468, v1] Follow up: Remove obsolete VIEW_CONVERT

On Wed, Aug 21, 2024 at 12:17:46PM +0200, Andre Vehreschild wrote: > > attached small patch removes a VIEW_CONVERT that I erroneously inserted during > patching pr110033. PR86468 fixes the (co-)rank computation and therefore this > VIEW_CONVERT is IMO obsolete. I think it may cause hard to find ru

Re: [PATCH 2/2] libstdc++: Implement P2997R1 changes to the indirect invocability concepts

On Wed, 21 Aug 2024, Jonathan Wakely wrote: > On Wed, 21 Aug 2024 at 01:40, Patrick Palka wrote: > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps > > 14? > > > > -- >8 -- > > > > This implements the changes of this C++26 paper as a DR against C++20. > > > > libstdc++

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

On Wed, Aug 21, 2024 at 03:27:56PM +, Qing Zhao wrote: > > On Aug 21, 2024, at 10:45, Martin Uecker wrote: > > > > Am Mittwoch, dem 21.08.2024 um 16:34 +0200 schrieb Martin Uecker: > >> Am Mittwoch, dem 21.08.2024 um 14:12 + schrieb Qing Zhao: > >> > >>> > >>> Yes, I do feel that the ap

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

On Wed, Aug 21, 2024 at 05:43:42PM +0200, Martin Uecker wrote: > Am Mittwoch, dem 21.08.2024 um 15:24 + schrieb Qing Zhao: > > > > > > But if we changed it to return a void pointer, we could make this > > > a compile-time check: > > > > > > auto ret = __builtin_get_counted_by(__p->FAM); > >

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

> On Aug 21, 2024, at 11:43, Martin Uecker wrote: > > Am Mittwoch, dem 21.08.2024 um 15:24 + schrieb Qing Zhao: >>> >>> But if we changed it to return a void pointer, we could make this >>> a compile-time check: >>> >>> auto ret = __builtin_get_counted_by(__p->FAM); >>> >>> _Generic(ret

[patch] libgomp.texi: Document OpenMP's Interoperability Routines

Add documentation for OpenMP's interoperability routines. This obviously, depends on the actual implementation patch, posted at: https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661035.html (albeit I will post a v2 in a moment). I am sure there will be comments, suggestions and remarks :

[PATCH v3 1/2] c++: improve location of parsed RETURN_EXPRs

For clarity, here's the entire split-up patch I intend to push, if it looks OK. Tested on x86_64-pc-linux-gnu. I've renamed the field we've discussed and also a few parameters that refer to 'kw' to be less specific. The code is functionally identical. OK for trunk? TIA, have a lovely day.

[PATCH v3 2/2] c++: improve diagnostic of 'return's in coroutines

We now point out why a function is a coroutine, and where (the first return) is in the function. gcc/cp/ChangeLog: * coroutines.cc (struct coroutine_info): Rename first_coro_keyword -> first_coro_expr. The former name is no longer accurate. (coro_promise_type_foun

Re: [PATCH] c++: Partially implement CWG 2867 - Order of initialization for structured bindings [PR115769]

On 8/14/24 3:41 AM, Jakub Jelinek wrote: Hi! The following patch partially implements CWG 2867 - Order of initialization for structured bindings. The DR requires that initialization of e is sequenced before r_i and that r_i initialization is sequenced before r_j for j > i, we already do it that

Re: [PATCH v3 1/2] c++: improve location of parsed RETURN_EXPRs

On 8/21/24 1:52 PM, Arsen Arsenović wrote: For clarity, here's the entire split-up patch I intend to push, if it looks OK. Tested on x86_64-pc-linux-gnu. I've renamed the field we've discussed and also a few parameters that refer to 'kw' to be less specific. The code is functionally identical.

[PATCH 0/9] c++, coroutines: Patch set for ramp function fixes.

This is a series of patches that addresses the majority of the open PRs related to the coroutine ramp function. It is presented as a series because the actual bug fixes depend on some preparatory patches (which are also used to resolve issues with other PR fixes - e.g. Arsen's fix for PR109867).

[PATCH 1/9] c++, coroutines: Split the ramp build into a separate function.

This is primarily preparation to partition the functionality of the coroutine transform into analysis, ramp generation and then (later) synthesis of the coroutine body. The patch does fix one latent issue in the ordering of DTORs for frame parameter copies (to ensure that they are processed in rev

[PATCH 5/9] c++, coroutines: Only allow void get_return_object if the ramp is void [PR100476].

Require that the value returned by get_return_object is convertible to the ramp return. This means that the only time we allow a void get_return_object, is when the ramp is also a void function. We diagnose this early to allow us to exit the ramp build if the return values are incompatible.

  1   2   >