Re: Patch ping (Re: [PATCH] combine: Special case set_noop_p in two spots)

On 4/28/25 1:26 AM, Jakub Jelinek wrote: On Fri, Mar 28, 2025 at 12:20:18PM +0100, Jakub Jelinek wrote: Here is the incremental patch I was talking about. For noop sets, we don't need to test much, they can go to i2 unless that would violate i3 JUMP condition. With this the try_combine on th

Re: Patch ping [PATCH] tailc: Don't fail musttail calls if they use or could use local arguments, instead warn [PR119376]

On Tue, 1 Apr 2025, Jakub Jelinek wrote: > Hi! > > On Tue, Mar 25, 2025 at 08:34:10AM +0100, Jakub Jelinek wrote: > > As discussed here and in bugzilla, [[clang::musttail]] attribute in clang > > not just strongly asks for tail call or error, but changes behavior. > > To quote: > > https://clang.

Re: Patch ping [PATCH] tailc: Don't fail musttail calls if they use or could use local arguments, instead warn [PR119376]

> I'd like to ping the > https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679182.html > patch. > I know it is quite controversial and if clang wouldn't be the first > to implement this I'd certainly not go that way; I am willing to change > the warning option names or move the maybe one from -W

Re: Patch ping - [PATCH] [APX EGPR] Fix indirect call prefix

On Mon, Nov 25, 2024 at 2:32 PM Kong, Lingling wrote: > > Hi, > > LGTM. > Now Hongyu and Hongtao are working on APX. Ok. > > Thanks, > Lingling > > > -Original Message- > > From: Gregory Kanter > > Sent: Saturday, November 23, 2024 8:16 AM > > To: gcc-patches@gcc.gnu.org > > Cc: Kong, Lin

RE: Patch ping - [PATCH] [APX EGPR] Fix indirect call prefix

Hi, LGTM. Now Hongyu and Hongtao are working on APX. Thanks, Lingling > -Original Message- > From: Gregory Kanter > Sent: Saturday, November 23, 2024 8:16 AM > To: gcc-patches@gcc.gnu.org > Cc: Kong, Lingling ; Gregory Kanter > > Subject: Patch ping - [PATCH] [APX EGPR] Fix indirect ca

Re: Patch ping - Re: [PATCH] genmatch: Add selftests to genmatch for diag_vfprintf

On Fri, 25 Oct 2024, Jakub Jelinek wrote: > On Tue, Oct 15, 2024 at 11:47:45AM +0200, Jakub Jelinek wrote: > > The following patch adds selftests to genmatch to verify the new printing > > routine there. > > So that I can rely on HAVE_DECL_FMEMOPEN (host test), the tests are done > > solely in sta

Re: [PATCH Ping] i386: Use BLKmode for {ld,st}tilecfg

On Fri, Jul 26, 2024 at 2:28 PM Jiang, Haochen wrote: > > Ping for this patch > > Thx, > Haochen > > > -Original Message- > > From: Haochen Jiang > > Sent: Thursday, July 18, 2024 9:45 AM > > To: gcc-patches@gcc.gnu.org > > Cc: Liu, Hongtao ; hjl.to...@gmail.com; > > ubiz...@gmail.com > >

RE: [PATCH Ping] i386: Use BLKmode for {ld,st}tilecfg

Ping for this patch Thx, Haochen > -Original Message- > From: Haochen Jiang > Sent: Thursday, July 18, 2024 9:45 AM > To: gcc-patches@gcc.gnu.org > Cc: Liu, Hongtao ; hjl.to...@gmail.com; > ubiz...@gmail.com > Subject: [PATCH] i386: Use BLKmode for {ld,st}tilecfg > > Hi all, > > For AM

Re: Patch ping

On Mon, Jun 17, 2024 at 03:26:52PM +0200, Jakub Jelinek wrote: > I'd like to ping the > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653573.html > patch. While the committed and backported patch fixed PCH on PIE > cc1/cc1plus etc. on PowerPC, it grew up the size of the > rs6000_init_generat

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

> > + if (POINTER_TYPE_P (TREE_TYPE (t1))) > > +{ > > + if (SSA_NAME_PTR_INFO (t1)) > > + { > > + if (!SSA_NAME_PTR_INFO (t2) > > + || SSA_NAME_PTR_INFO (t1)->align != SSA_NAME_PTR_INFO (t2)->align > > + || SSA_NAME_PTR_INFO (t1)->misalign != SSA_NAME_PTR_INFO > > (

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Thu, 14 Mar 2024, Jan Hubicka wrote: > > > We have wrong code with LTO, too. > > > > I know. > > > > > The problem is that IPA passes (and > > > not only that, loop analysis too) does analysis at compile time (with > > > value numbers in) and streams the info separately. > > > > And that is

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

> > Otherwise > > I will add your testcase for this patch and commit this one. > > Statistically we almost never merge functions with different value > > ranges (three in testsuite, 0 during bootstrap, 1 during LTO bootstrap > > and probably few in LLVM build - there are 15 cases reported, but some

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Thu, Mar 14, 2024 at 05:16:59PM +0100, Jan Hubicka wrote: > Sorry, this was bit of a misunderstanding: I tought you still considered > the original patch to be full fix, while I tought I should look into it > more and dig out more issues. This is bit of can of worms. Overall I > think the plan

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

> > We have wrong code with LTO, too. > > I know. > > > The problem is that IPA passes (and > > not only that, loop analysis too) does analysis at compile time (with > > value numbers in) and streams the info separately. > > And that is desirable, because otherwise it simply couldn't derive any

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

> > int test (int a) > > { > > return a>0 ? CST1: CST2; > > } > > > > gets same hash value no matter what CST1/CST2 is. I added hasher and I > > am re-running stats. > > The hash should be commutative here at least. It needs to match what comparator is doing later, and sadly it does not try to

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Wed, Mar 13, 2024 at 12:18:45PM +0100, Jan Hubicka wrote: > > On Wed, Mar 13, 2024 at 10:55:07AM +0100, Jan Hubicka wrote: > > > > > So the ipa_jump_func are I think the only thing that actually can > > > > > differ > > > > > on the ICF merging candidates from value range POV. > > > > > > > >

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

> On Wed, Mar 13, 2024 at 10:55:07AM +0100, Jan Hubicka wrote: > > > > So the ipa_jump_func are I think the only thing that actually can differ > > > > on the ICF merging candidates from value range POV. > > > > > > I agree. Btw, I would have approved the original patch in this > > > thread that

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Wed, Mar 13, 2024 at 10:55:07AM +0100, Jan Hubicka wrote: > > > So the ipa_jump_func are I think the only thing that actually can differ > > > on the ICF merging candidates from value range POV. > > > > I agree. Btw, I would have approved the original patch in this > > thread that wipes SSA_NA

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Wed, 13 Mar 2024, Jan Hubicka wrote: > > On Tue, 12 Mar 2024, Jakub Jelinek wrote: > > > > > On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote: > > > > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote: > > > > > I am sorry for delaying this. I made the variant that simp

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

> On Tue, 12 Mar 2024, Jakub Jelinek wrote: > > > On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote: > > > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote: > > > > I am sorry for delaying this. I made the variant that simply compares > > > > value range of functions and pr

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Tue, 12 Mar 2024, Jakub Jelinek wrote: > On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote: > > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote: > > > I am sorry for delaying this. I made the variant that simply compares > > > value range of functions and prevents mergi

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote: > On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote: > > I am sorry for delaying this. I made the variant that simply compares > > value range of functions and prevents merging if they diverge and wanted > > to make some bigg

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote: > I am sorry for delaying this. I made the variant that simply compares > value range of functions and prevents merging if they diverge and wanted > to make some bigger statistics. This made me notice some performance > problems on clan

Re: Patch ping Re: [PATCH] icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]

> Hi! Hi, > > On Thu, Feb 15, 2024 at 08:29:24AM +0100, Jakub Jelinek wrote: > > 2024-02-15 Jakub Jelinek > > > > PR middle-end/113907 > > * ipa-icf.cc (sem_item_optimizer::merge_classes): Reset > > SSA_NAME_RANGE_INFO and SSA_NAME_PTR_INFO on successfully ICF merged > > functi

Re: Patch ping^2

> Hi! > > I'd like to ping 2 patches: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644580.html > > > PR113617 P1 - Handle private COMDAT function symbol reference in

Re: Patch ping^2

On Mon, Feb 26, 2024 at 10:33 AM Jakub Jelinek wrote: > > Hi! > > I'd like to ping 2 patches: > https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645326.html > i386: Enable _BitInt support on ia32 > > all the FAILs mentioned in that mail have been fixed by now. LGTM, based on HJ's advice.

Re: Patch ping

On 2/9/24 02:44, Jakub Jelinek wrote: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html Introduce HOST_SIZE_T_PRINT_UNSIGNED etc. macros to fix LLP64 host build issue Both have been successfully bootstrapped/regtested on x86_64-linux and i686-linux, the latter has been tes

Re: Patch ping: [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377]

On Tue, 2023-09-19 at 09:20 +0200, Jakub Jelinek wrote: > Hi! > > On Tue, Sep 12, 2023 at 09:02:55AM +0200, Jakub Jelinek via Gcc- > patches wrote: > > On Mon, Sep 11, 2023 at 11:11:30PM +0200, Jakub Jelinek via Gcc- > > patches wrote: > > > On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priou

Re: Patch ping: Re: [PATCH] c, c++, v2: Accept __builtin_classify_type (typename)

On Mon, 18 Sep 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > I'd like to ping this patch. > The C++ FE part has been approved by Jason already with a minor change > I've made in my copy. > Are the remaining parts ok for trunk? In the C front-end changes, since you end up discarding any si

Re: Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989]

On Mon, Aug 21, 2023 at 8:25 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > On Wed, Aug 09, 2023 at 08:14:14PM +0200, Jakub Jelinek via Gcc-patches wrote: > > Jakub Jelinek (12): > > expr: Small optimization [PR102989] > > lto-streamer-in: Adjust assert [PR102989] > > phiopt: Fix phiopt

Re: Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989]

On Mon, 21 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > Joseph, could I ask now at least for an overall design review of the > C patches (8-10,13) whether its interfaces with middle-end are ok, > so that Richi can review the middle-end parts? I am fine with the interface to the middle-end par

Re: Patch ping (Re: [PATCH] middle-end, i386: Pattern recognize add/subtract with carry [PR79173])

On Tue, Jun 13, 2023 at 9:06 AM Jakub Jelinek wrote: > > Hi! > > On Tue, Jun 06, 2023 at 11:42:07PM +0200, Jakub Jelinek via Gcc-patches wrote: > > The following patch introduces {add,sub}c5_optab and pattern recognizes > > various forms of add with carry and subtract with carry/borrow, see > > pr

Re: Patch ping Re: [PATCH] ipa: Avoid another ICE when dealing with type-incompatibilities (PR 108959)

> On Thu, Mar 23, 2023 at 11:09:19AM +0100, Martin Jambor wrote: > > Hi, > > > > PR 108959 shows one more example where undefined code with type > > incompatible accesses to stuff passed in parameters can cause an ICE > > because we try to create a VIEW_CONVERT_EXPR of mismatching sizes: > > > >

Re: Patch ping: Re: [PATCH] libgcc, i386, optabs, v2: Add __float{, un}tibf to libgcc and expand BF -> integral through SF intermediate [PR107703]

On 3/1/23 05:32, Jakub Jelinek via Gcc-patches wrote: Hi! On Wed, Nov 16, 2022 at 12:51:14PM +0100, Jakub Jelinek via Gcc-patches wrote: On Wed, Nov 16, 2022 at 10:06:17AM +0100, Jakub Jelinek via Gcc-patches wrote: Thoughts on this? I guess my preference would be the BF -> SF -> TI path b

Re: Patch ping: Re: [PATCH] libgcc, i386, optabs, v2: Add __float{, un}tibf to libgcc and expand BF -> integral through SF intermediate [PR107703]

On Fri, Mar 10, 2023 at 7:11 PM Ian Lance Taylor wrote: > > Jakub Jelinek writes: > > > On Wed, Mar 01, 2023 at 01:32:43PM +0100, Jakub Jelinek via Gcc-patches > > wrote: > >> On Wed, Nov 16, 2022 at 12:51:14PM +0100, Jakub Jelinek via Gcc-patches > >> wrote: > >> > On Wed, Nov 16, 2022 at 10:0

Re: Patch ping: Re: [PATCH] libgcc, i386, optabs, v2: Add __float{, un}tibf to libgcc and expand BF -> integral through SF intermediate [PR107703]

Jakub Jelinek writes: > On Wed, Mar 01, 2023 at 01:32:43PM +0100, Jakub Jelinek via Gcc-patches wrote: >> On Wed, Nov 16, 2022 at 12:51:14PM +0100, Jakub Jelinek via Gcc-patches >> wrote: >> > On Wed, Nov 16, 2022 at 10:06:17AM +0100, Jakub Jelinek via >> > Gcc-patches wrote: >> > > Thoughts on

Re: Patch ping: [PATCH] cygwin: Don't try to support multilibs [PR107998]

On 3/10/23 09:37, Jakub Jelinek wrote: Hi! I'd like to ping this patch (as I wrote a week ago, NightStrike has tested it): Thanks, pushed to master branch.

Re: Patch ping - [PATCH] file-prefix-map: Fix up -f*-prefix-map= [PR108464]

On Fri, 2023-03-10 at 09:05 +, Richard Biener wrote: > On Fri, 10 Mar 2023, Jakub Jelinek wrote: > > > Hi! > > > > I'd like to ping these patches. All 3 variants have been > > bootstrapped/regtested on x86_64-linux and i686-linux, the last > > one is my preference I guess. The current state

Re: Patch ping - [PATCH] tree: Use comdat tree_code_{type,length} even for C++11/14 [PR108634]

On Fri, 10 Mar 2023, Jakub Jelinek wrote: > Hi! > > I'd like to ping this patch, which has been successfully > bootstrapped/regtested on x86_64-linux and i686-linux: > > https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611180.html > - PR108634 - P3 - tree: Use comdat tree_code_{type,len

Re: Patch ping - [PATCH] file-prefix-map: Fix up -f*-prefix-map= [PR108464]

On Fri, 10 Mar 2023, Jakub Jelinek wrote: > Hi! > > I'd like to ping these patches. All 3 variants have been > bootstrapped/regtested on x86_64-linux and i686-linux, the last > one is my preference I guess. The current state breaks e.g. ccache. > > https://gcc.gnu.org/pipermail/gcc-patches/202

Re: Patch ping

On Wed, 1 Mar 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > I'd like to ping a few pending patches: > > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html > - PR107846 - P1 - c-family: Account for integral promotions of left shifts > for -Wshift-overflow warning OK.

Re: Patch ping

Jakub Jelinek writes: > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605965.html > - ABI - aarch64: Add bfloat16_t support for aarch64 (enabling it in GCC 14 > will be harder) Sorry for the delay on this. There's still an ongoing debate about whether to keep the current AArch64

Re: [PATCH PING 2 (tree)] c++: source position of lambda captures [PR84471]

On 12/2/22 10:45, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- If the DECL_VALUE_EXPR of a VAR_DECL has EXPR_LOCATION set, then any use of that variable looks like it has that location, which leads to the debugger jumping back and forth for both lambdas and structured

Re: [PATCH PING] build: add -Wconditionally-supported to strict_warn [PR64867]

On 12/6/22 08:26, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, OK for trunk? Ping. -- 8< -- The PR (which isn't resolved by this commit) pointed out to me that GCC should build with -Wconditionally-supported to support bootstrapping with a C++11 compiler that makes different choices.

Re: [PATCH][PING][sanitizer/106558] asan: fix unsafe optimization of Asan checks.

On 11/25/22 17:18, Martin Liška wrote: On 11/21/22 11:02, Jakub Jelinek wrote: Otherwise LGTM. Thanks and sorry for the review delay. Yuri, do you want to commit the patch soon? If not, I can help if you want? Hey. I've just installed the patch with function signature change and changelog

Re: [PATCH][PING][sanitizer/106558] asan: fix unsafe optimization of Asan checks.

On 11/21/22 11:02, Jakub Jelinek wrote: > Otherwise LGTM. Thanks and sorry for the review delay. Yuri, do you want to commit the patch soon? If not, I can help if you want? Cheers, Martin

Re: [PATCH][PING][sanitizer/106558] asan: fix unsafe optimization of Asan checks.

On Mon, Nov 21, 2022 at 12:57:15PM +0300, Yuri Gribov wrote: > From 4729f2db3f1b6b40ef0124e4a645788d7f66f426 Mon Sep 17 00:00:00 2001 > From: Yuri Gribov > Date: Sun, 14 Aug 2022 08:42:44 +0300 > Subject: [PATCH] asan: fix unsafe optimization of Asan checks. > > gcc/ > PR sanitizer/106558

Re: Patch ping (Re: [PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for)

I'm seeing the following build failure for arc-linux-gnu after this commit. (Note that this is for building GCC *after* glibc, not for an initial inhibit_libc bootstrap build of GCC.) In file included from /scratch/jmyers/glibc-bot/src/gcc/libgcc/unwind-dw2.c:413: ./md-unwind-support.h: In fun

Re: Patch ping (Re: [PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for)

On Wed, Oct 5, 2022 at 12:34 PM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > I'd like to ping this patch. The patch is OK. Richard. > Thanks. > > > 2022-09-19 Jakub Jelinek > > > > * unwind-dw2.h (REG_UNSAVED, REG_SAVED_OFFSET, REG_SAVED_REG, > > REG_SAVED_EXP, REG_SAVED_VAL_

Re: Patch ping^3 ([PATCH] libstdc++: Outline the overlapping case of string _M_replace into a separate function [PR105329])

On Mon, 12 Sept 2022 at 10:16, Jakub Jelinek wrote: > > On Wed, Aug 31, 2022 at 11:38:58AM +0200, Jakub Jelinek via Gcc-patches wrote: > > On Wed, Aug 10, 2022 at 01:27:51PM +0200, Jakub Jelinek via Gcc-patches > > wrote: > > > On Wed, Jul 27, 2022 at 11:33:29AM +0200, Jakub Jelinek via Gcc-patch

Re: Patch ping (was Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange)

On Fri, 9 Sept 2022 at 20:01, Thomas Rodgers wrote: > > s/__weak/__is_weak/g perhaps? Yes, that'll do. Fixed by the attached, with a test to avoid it happening again. Tested x86_64-linux, pushed to trunk. > > On Fri, Sep 9, 2022 at 11:46 AM Iain Sandoe via Libstdc++ > wrote: >> >> >> >> >

Re: Patch ping (was Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange)

s/__weak/__is_weak/g perhaps? On Fri, Sep 9, 2022 at 11:46 AM Iain Sandoe via Libstdc++ < libstd...@gcc.gnu.org> wrote: > > > > On 9 Sep 2022, at 19:36, Rainer Orth > wrote: > > > > >> Here's a complete patch that combines the various incremental patches > >> that have been going around. I'm te

Re: Patch ping (was Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange)

> On 9 Sep 2022, at 19:36, Rainer Orth wrote: > >> Here's a complete patch that combines the various incremental patches >> that have been going around. I'm testing this now. >> >> Please take a look. > > unfortunately, this patch broke macOS bootstrap (seen on > x86_64-apple-darwin11.4.2):

Re: Patch ping (was Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange)

Hi Jonathan, > Here's a complete patch that combines the various incremental patches > that have been going around. I'm testing this now. > > Please take a look. unfortunately, this patch broke macOS bootstrap (seen on x86_64-apple-darwin11.4.2): In file included from /var/gcc/regression/master

Re: Patch ping (was Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange)

Looks good to me. Tom. On Wed, Sep 7, 2022 at 4:56 AM Jonathan Wakely wrote: > Here's a complete patch that combines the various incremental patches > that have been going around. I'm testing this now. > > Please take a look. >

Re: Patch ping (was Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange)

Here's a complete patch that combines the various incremental patches that have been going around. I'm testing this now. Please take a look. commit 4a0a8ec5bc2a890a1568f99eace666e9f72d Author: Thomas Rodgers Date: Thu Aug 25 11:11:40 2022 libstdc++: Clear padding bits in atomic compare

Re: Patch ping (was Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange)

Sorry for the delay in getting to this. I am currently working on moving the bulk of the atomic wait implementation into the .so. I'd like to get that work to a stable state before revisiting this patch, but obviously if we want this to make it into GCC13, it needs to happen sooner rather than lat

Re: Patch ping (Re: [PATCH] Implement __builtin_issignaling)

On Tue, 23 Aug 2022, Jakub Jelinek via Gcc-patches wrote: > On Tue, Aug 16, 2022 at 11:41:06AM +, Richard Biener wrote: > > I'm OK with the rest of the patch if Joseph doesn't have comments > > on the actual issignaling lowerings (which I didn't review for > > correctness due to lack of knowle

Re: Patch ping Re: [PATCH] i386: Fix up ix86_gimplify_va_arg [PR105331]

On 4/28/2022 4:31 AM, Richard Biener wrote: On Thu, 28 Apr 2022, Jakub Jelinek wrote: On Thu, Apr 28, 2022 at 10:39:39AM +0200, Uros Bizjak wrote: Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2022-04-22 Jakub Jelinek PR target/105331 * config/i386/

Re: Patch ping Re: [PATCH] i386: Fix up ix86_gimplify_va_arg [PR105331]

On Thu, 28 Apr 2022, Jakub Jelinek wrote: > On Thu, Apr 28, 2022 at 10:39:39AM +0200, Uros Bizjak wrote: > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > > > > > > > 2022-04-22 Jakub Jelinek > > > > > > > > PR target/105331 > > > > * config/i386/i386.

Re: Patch ping Re: [PATCH] i386: Fix up ix86_gimplify_va_arg [PR105331]

On Thu, Apr 28, 2022 at 10:39:39AM +0200, Uros Bizjak wrote: > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > > > > > 2022-04-22 Jakub Jelinek > > > > > > PR target/105331 > > > * config/i386/i386.cc (ix86_gimplify_va_arg): Mark va_arg_tmp > > > te

Re: Patch ping Re: [PATCH] i386: Fix up ix86_gimplify_va_arg [PR105331]

On Thu, Apr 28, 2022 at 10:31 AM Jakub Jelinek wrote: > > Hi! > > I'd like to ping this patch. I know it isn't a full week yet, but we are > almost out of P1s and GCC 12 branching is any time now. > > Thanks: > On Fri, Apr 22, 2022 at 09:25:04AM +0200, Jakub Jelinek via Gcc-patches wrote: > > On

Re: [PATCH PING] ipa: Careful processing ANCESTOR jump functions and NULL pointers (PR 103083)

Hello, I would like to ping this patch, please. Thanks, Martin On Mon, Feb 14 2022, Martin Jambor wrote: > Hello Honza, > > On Mon, Dec 13 2021, Jan Hubicka wrote: >>> >>> + || (only_for_nonzero && >>> >>> !src_lats->bits_lattice.known_nonzero_p ())) >>> >>> + { >>> >>> +

Re: [PATCH PING] ipa-cp: Do not create clones for values outside known value range (PR 102513)

Hello, I would like to ping this patch, please. Thanks, Martin On Mon, Feb 14 2022, Martin Jambor wrote: > Hi, > > PR 102513 shows we emit bogus array access warnings when IPA-CP > creates clones specialized for values which it deduces from arithmetic > jump functions describing self-recursive

Re: Patch ping (Re: [PATCH] libatomic: Improve 16-byte atomics on Intel AVX [PR104688])

On Wed, Mar 16, 2022 at 6:50 PM Jakub Jelinek wrote: > > Hi! > > I'd like to ping this patch: > https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590960.html > > Thanks. > > On Mon, Feb 28, 2022 at 07:06:30AM +0100, Jakub Jelinek wrote: > > As mentioned in the PR, the latest Intel SDM has ad

Re: Patch ping

On 3/2/2022 2:47 AM, Jakub Jelinek wrote: Hi! I'd like to ping the https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590526.html PR104558 - when bypassing emit_push_insn for 0 sized arg, emit at least anti_adjust_stack for alignment pad if needed patch. So the issue is the stack isn'

Re: Patch ping

> Hi! > > I'd like to ping the > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html > symtab: Fold &a == &b to 0 if folding_initializer [PR94716] > > patch. Thanks. OK. Note that with LTO partitioning it may happen that alias is defined in one partition but used in another. W

Re: Patch ping

On Mon, 3 Jan 2022, Jakub Jelinek wrote: > Hi! > > I'd like to ping the > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html > symtab: Fold &a == &b to 0 if folding_initializer [PR94716] OK. Thanks, Richard.

Re: Patch ping

On Mon, 3 Jan 2022, Jakub Jelinek wrote: > Hi! > > I'd like to ping the middle-end part of the > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586879.html > patch (which Uros approved the backend part for with a minor change > I have in my tree). OK for the middle-end parts if you prop

Re: Patch ping related to OpenMP

Thanks for a DWARF-related patch review (+ fix by yourself). Otherwise, still pending are the following OpenMP patches. The first one is a revised patch following the review comment and affects Fortran only. The second one is also a rather small & post-review revised patch. On 06.12.21 15:56, To

Re: Patch ping related to OpenMP

First, thanks for the four reviews. Secondly, I missed one patch – hence, reposted with all three pending patches: * Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0). https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584894.html and: On 01.12.21 17:34, Tobias Burnus wro

Re: Patch ping (Re: [PATCH] x86_64: Issue -Wpsabi warning about C++ zero width bitfield ABI changes [PR102024])

On Mon, Nov 29, 2021 at 3:24 AM Jakub Jelinek wrote: > > Hi! > > On Tue, Aug 31, 2021 at 10:05:58AM +0200, Jakub Jelinek via Gcc-patches wrote: > > This is an incremental patch to > > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578447.html > > for x86_64 ABI. > > For zero-width bitfields

Re: Patch ping (was Re: [PATCH] rs6000: Fix up easy_vector_constant_msb handling [PR101384])

Hi! On Tue, Jul 20, 2021 at 02:43:03PM +0200, Jakub Jelinek wrote: > For gcc 11, I've bootstrapped/regtested on powerpc64le-linux and > powerpc64-linux (the latter regtested -m32/-m64) also a simpler version > below, which restricts it to the case that the code handles properly. > > 2021-07-20 J

Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)

> Is just using std::terminate as the handler viable? Or if we're sure > contracts in some form will go into the IS eventually, and the > signature won't change, we could just add it in __cxxabiv1:: as you > suggested earlier. No, the handler needs to be configurable (at least quietly) in order to

Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)

On Wed, 14 Jul 2021 at 04:56, Jason Merrill wrote: > > On 7/12/21 3:58 PM, Jonathan Wakely wrote: > > On Mon, 5 Jul 2021 at 20:07, Jason Merrill wrote: > >> > >> On 6/26/21 10:23 AM, Andrew Sutton wrote: > >>> > >>> I ended up taking over this work from Jeff (CC'd on his existing email > >>> addr

Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)

On 7/12/21 3:58 PM, Jonathan Wakely wrote: On Mon, 5 Jul 2021 at 20:07, Jason Merrill wrote: On 6/26/21 10:23 AM, Andrew Sutton wrote: I ended up taking over this work from Jeff (CC'd on his existing email address). I scraped all the contracts changes into one big patch against master. See a

Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)

On Mon, 5 Jul 2021 at 20:07, Jason Merrill wrote: > > On 6/26/21 10:23 AM, Andrew Sutton wrote: > > > > I ended up taking over this work from Jeff (CC'd on his existing email > > address). I scraped all the contracts changes into one big patch > > against master. See attached. The ChangeLog.contra

Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)

On 7/5/21 3:07 PM, Jason Merrill wrote: On 6/26/21 10:23 AM, Andrew Sutton wrote: I ended up taking over this work from Jeff (CC'd on his existing email address). I scraped all the contracts changes into one big patch against master. See attached. The ChangeLog.contracts files list the sum of c

contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)

On 6/26/21 10:23 AM, Andrew Sutton wrote: I ended up taking over this work from Jeff (CC'd on his existing email address). I scraped all the contracts changes into one big patch against master. See attached. The ChangeLog.contracts files list the sum of changes for the patch, not the full histor

Re: [PATCH] PING implement pre-c++20 contracts

I think so, yes. On Fri, Jul 2, 2021 at 11:09 AM Jason Merrill wrote: > > On 7/1/21 12:27 PM, Andrew Sutton wrote: > >>> I think this version addresses most of your concerns. > >> > >> Thanks, looking good. I'll fuss with it a bit and commit it soon. > > Do you agree that this testcase should co

Re: [PATCH] PING implement pre-c++20 contracts

On 7/1/21 12:27 PM, Andrew Sutton wrote: I think this version addresses most of your concerns. Thanks, looking good. I'll fuss with it a bit and commit it soon. Do you agree that this testcase should compile? >From 85400e1896a188892b1ebeb0c8e86ff3cd28cfa6 Mon Sep 17 00:00:00 2001 From: Jason

Re: [PATCH] PING implement pre-c++20 contracts

> > I think this version addresses most of your concerns. > > Thanks, looking good. I'll fuss with it a bit and commit it soon. Awesome! Andrew

Re: [PATCH] PING implement pre-c++20 contracts

On 6/26/21 10:23 AM, Andrew Sutton wrote: Hi Jason, I ended up taking over this work from Jeff (CC'd on his existing email address). I scraped all the contracts changes into one big patch against master. See attached. The ChangeLog.contracts files list the sum of changes for the patch, not the f

Re: [PATCH] PING implement pre-c++20 contracts

Hello again :) Wanted to shoot a quick status update. Some github issues have been created for points of feedback, and we've been working on addressing them. A few changes have been pushed to the contracts-jac-alt branch, while there's also an active more in depth rewrite branch. Some specific com

Re: [PATCH] PING implement pre-c++20 contracts

On 5/14/21 4:54 PM, Jason Merrill wrote: On 4/30/21 1:44 PM, Jeff Chapman wrote: Hello! Looping back around to this. re: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567334.html On 3/25/21, Jason Merrill wrote: On 3/1/21 8:12 AM, Jeff Chapman wrote: On 1/18/21, Jason Merrill wrote:

Re: [PATCH] PING implement pre-c++20 contracts

On Fri, May 14, 2021 at 04:54:10PM -0400, Jason Merrill via Gcc-patches wrote: > Please add an overview of the implementation strategy to the top of > cxx-contracts.c. Particularly to discuss the why and how of > pre/post/guarded/unguarded functions. And I think let's please name the file contrac

Re: [PATCH] PING implement pre-c++20 contracts

On 4/30/21 1:44 PM, Jeff Chapman wrote: Hello! Looping back around to this. re: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567334.html On 3/25/21, Jason Merrill wrote: On 3/1/21 8:12 AM, Jeff Chapman wrote: On 1/18/21, Jason Merrill wrote: On 1/4/21 9:58 AM, Jeff Chapman wrote: P

Re: Patch ping (Re: [PATCH] ix86: Support V{2, 4}DImode arithmetic right shifts for SSE2+ [PR98856])

On Wed, May 12, 2021 at 3:06 PM Jakub Jelinek wrote: > > On Fri, Apr 23, 2021 at 03:46:59PM +0200, Jakub Jelinek via Gcc-patches wrote: > > On Tue, Feb 09, 2021 at 12:12:24PM +0100, Jakub Jelinek via Gcc-patches > > wrote: > > > As mentioned in the PR, we don't support arithmetic right V2DImode o

Re: [PATCH] PING implement pre-c++20 contracts

Hello! Looping back around to this. re: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567334.html On 3/25/21, Jason Merrill wrote: > On 3/1/21 8:12 AM, Jeff Chapman wrote: >> On 1/18/21, Jason Merrill wrote: >>> On 1/4/21 9:58 AM, Jeff Chapman wrote: Ping. re: https://gcc.gnu.or

Re: Patch ping for PR95176 fix

On 4/12/2021 11:45 AM, Victor Tong via Gcc-patches wrote: Hello, I'd like to ping this patch. It contains two new tree-opt patterns in match.pd. [PATCH] tree-optimization: Optimize division followed by multiply [PR95176] (gnu.org)

Re: Patch ping

On Wed, 31 Mar 2021, Jakub Jelinek wrote: > Hi! > > I'd like to ping the PR98860 P1 fix - workaround for PECOFF linkers without > DWARF5 support - to make -gdwarf-4 the default in such configurations. > > https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567245.html OK. Richard. > Thanks >

Re: [PATCH] PING implement pre-c++20 contracts

On 3/1/21 8:12 AM, Jeff Chapman wrote: On 1/18/21, Jason Merrill wrote: On 1/4/21 9:58 AM, Jeff Chapman wrote: Ping. re: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561135.html https://github.com/lock3/gcc/tree/

Re: Patch ping

On Wed, 24 Mar 2021, Martin Sebor wrote: > On 3/24/21 10:40 AM, Jakub Jelinek wrote: > > On Wed, Mar 24, 2021 at 09:45:31AM -0600, Martin Sebor via Gcc-patches > > wrote: > >> E.g., OEP_IGNORE_MEMBER_OFFSET or OEP_SAME_MEMBER_OFFSET (for > >> the converse of the first) or something like that, but

Re: Patch ping

On 3/24/21 10:40 AM, Jakub Jelinek wrote: On Wed, Mar 24, 2021 at 09:45:31AM -0600, Martin Sebor via Gcc-patches wrote: E.g., OEP_IGNORE_MEMBER_OFFSET or OEP_SAME_MEMBER_OFFSET (for the converse of the first) or something like that, but hopefully you get the idea. Neither of these look like a

Re: Patch ping

On Wed, Mar 24, 2021 at 09:45:31AM -0600, Martin Sebor via Gcc-patches wrote: > E.g., OEP_IGNORE_MEMBER_OFFSET or OEP_SAME_MEMBER_OFFSET (for > the converse of the first) or something like that, but hopefully > you get the idea. Neither of these look like a good name to me, OEP_IGNORE_MEMBER_OFFSE

Re: Patch ping

On 3/24/2021 5:44 AM, Jakub Jelinek via Gcc-patches wrote: Hi! I'd like to ping the https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566821.html P1 PR99565 fix. Marek has acked the gcc/c/ and gcc/c-family/ part of that patch, but it still has gcc/cp/ and gcc/ parts that weren't acked. If

Re: Patch ping

On 3/24/21 5:44 AM, Jakub Jelinek via Gcc-patches wrote: Hi! I'd like to ping the https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566821.html P1 PR99565 fix. Marek has acked the gcc/c/ and gcc/c-family/ part of that patch, but it still has gcc/cp/ and gcc/ parts that weren't acked. If you

Re: [PATCH PING^3] Add input_modes parameter to TARGET_MD_ASM_ADJUST hook

On 3/3/21 1:42 PM, Ilya Leoshkevich wrote: > On Wed, 2021-03-03 at 21:26 +0100, Ilya Leoshkevich via Gcc-patches > wrote: >> On Wed, 2021-03-03 at 13:02 -0700, Jeff Law wrote: >>> >>> On 3/2/21 4:50 PM, Ilya Leoshkevich via Gcc-patches wrote: Hello, I would like to ping the follow

Re: [PATCH PING^3] Add input_modes parameter to TARGET_MD_ASM_ADJUST hook

On Wed, 2021-03-03 at 21:26 +0100, Ilya Leoshkevich via Gcc-patches wrote: > On Wed, 2021-03-03 at 13:02 -0700, Jeff Law wrote: > > > > > > On 3/2/21 4:50 PM, Ilya Leoshkevich via Gcc-patches wrote: > > > Hello, > > > > > > I would like to ping the following patch: > > > > > > Add input_modes p

Re: [PATCH PING^3] Add input_modes parameter to TARGET_MD_ASM_ADJUST hook

On Wed, 2021-03-03 at 13:02 -0700, Jeff Law wrote: > > > On 3/2/21 4:50 PM, Ilya Leoshkevich via Gcc-patches wrote: > > Hello, > > > > I would like to ping the following patch: > > > > Add input_modes parameter to TARGET_MD_ASM_ADJUST hook > > https://gcc.gnu.org/pipermail/gcc-patches/2021-Janu

  1   2   3   4   5   6   >