Patch ping

Hi! I'd like to ping 2 patches, one mine: P2 PR70001 http://gcc.gnu.org/ml/gcc-patches/2016-03/msg00710.html and one from Alex, which hasn't been pinged for quite a while, but is P1: P1 PR69315 https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02010.html Thanks. Jakub

Re: Patch ping

On 03/04/2016 12:30 AM, Jakub Jelinek wrote: Hi! I'd like to ping a texinfo fix for __builtin_alloca*: http://gcc.gnu.org/ml/gcc-patches/2016-02/msg01842.html OK. jeff

Patch ping

Hi! I'd like to ping a texinfo fix for __builtin_alloca*: http://gcc.gnu.org/ml/gcc-patches/2016-02/msg01842.html Jakub

Re: Patch ping

On Fri, Mar 04, 2016 at 12:10:26AM -0700, Jeff Law wrote: > On 03/03/2016 07:35 AM, Jakub Jelinek wrote: > >Hi! > > > >I'd like to ping fix for P1 PR69947: > >https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01743.html > So essentially this is just marking more things so that we don't prune them >

Re: Patch ping

On 03/03/2016 07:35 AM, Jakub Jelinek wrote: Hi! I'd like to ping fix for P1 PR69947: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01743.html So essentially this is just marking more things so that we don't prune them away, right? It's similar conceptually to one of Pierre-Marie's patches

Patch ping

Hi! I'd like to ping fix for P1 PR69947: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01743.html Jakub

Patch ping

Hi! I'd like to ping a C++ P1 fix for PR69658: http://gcc.gnu.org/ml/gcc-patches/2016-02/msg00352.html Jakub

Re: Patch ping

On Wed, 10 Feb 2016, Jakub Jelinek wrote: > Hi! > > I'd like to ping a P1 patch: > PR ipa/69241, PR c++/69649 > https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00192.html Ok. Thanks, Richard. > Jakub > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer,

Patch ping

Hi! I'd like to ping a P1 patch: PR ipa/69241, PR c++/69649 https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00192.html Jakub

RE: [RFA] Compact EH Patch [Ping^3]

> -Original Message- > From: Moore, Catherine > Sent: Tuesday, January 05, 2016 8:53 AM > To: Richard Henderson; ja...@redhat.com > Cc: gcc-patches@gcc.gnu.org > Subject: FW: [RFA] Compact EH Patch [Ping * 2] > > Ping, Ping. > > -Original Messa

[PATCH, PING] DWARF: process all TYPE_DECL nodes when iterating on scopes

Hello, Ping for the patch submitted in . Thanks! -- Pierre-Marie de Rodat

Re: C++ patch ping

On 01/11/2016 04:52 PM, Jakub Jelinek wrote: On Mon, Jan 11, 2016 at 04:44:46PM -0500, Jason Merrill wrote: On 01/11/2016 03:01 PM, Nathan Sidwell wrote: On 01/09/16 02:41, Jakub Jelinek wrote: Hi! I'd like to ping the PR c++/66808, PR c++/69000

Re: C++ patch ping

On Mon, Jan 11, 2016 at 04:44:46PM -0500, Jason Merrill wrote: > On 01/11/2016 03:01 PM, Nathan Sidwell wrote: > >On 01/09/16 02:41, Jakub Jelinek wrote: > >>Hi! > >> > >>I'd like to ping the PR c++/66808, PR c++/69000 > >>http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html > >>patch, fixing

Re: C++ patch ping

On Mon, Jan 11, 2016 at 05:04:16PM -0500, Jason Merrill wrote: > >You mean: > > > >--- gcc/cp/pt.c.jj 2016-01-05 16:46:02.891896607 +0100 > >+++ gcc/cp/pt.c 2016-01-11 21:33:09.065184178 +0100 > >@@ -12207,6 +12207,8 @@ tsubst_decl (tree t, tree args, tsubst_f > >

Re: C++ patch ping

On 01/11/2016 03:01 PM, Nathan Sidwell wrote: On 01/09/16 02:41, Jakub Jelinek wrote: Hi! I'd like to ping the PR c++/66808, PR c++/69000 http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html patch, fixing ICE with GNU __thread vars in templates. Can't you unconditionally clear

Re: C++ patch ping

OK. Jason

Re: C++ patch ping

On 01/09/16 02:41, Jakub Jelinek wrote: Hi! I'd like to ping the PR c++/66808, PR c++/69000 http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html patch, fixing ICE with GNU __thread vars in templates. Can't you unconditionally clear DECL_TEMPLATE_INFO regardless of local_p? if

C++ patch ping

Hi! I'd like to ping the PR c++/66808, PR c++/69000 http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02019.html patch, fixing ICE with GNU __thread vars in templates. Thanks Jakub

FW: [RFA] Compact EH Patch [Ping * 2]

EH Patch [Ping] > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Moore, Catherine > Sent: Sunday, December 13, 2015 5:12 PM > To: Richard Henderson; gcc-patches@gcc.gnu.org > Cc: ja...@redhat.com; Matthew

Re: [PATCH][PING][PR 67425] Fix docs for -frandom-seed

On 12/29/2015 12:33 AM, Yury Gribov wrote: Hi all, this patch reverts invalid documentation change -frandom-seed which was introduced by myself in r216773 a year ago. I've checked the generated man and the only test for -frandom-seed (gcc.dg/pr61868.c). Ok for trunk? I also want to backport

[PATCH][PING][PR 67425] Fix docs for -frandom-seed

Hi all, this patch reverts invalid documentation change -frandom-seed which was introduced by myself in r216773 a year ago. I've checked the generated man and the only test for -frandom-seed (gcc.dg/pr61868.c). Ok for trunk? I also want to backport to GCC5 branch. -Yura >From

RE: [RFA] Compact EH Patch [Ping]

> -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Moore, Catherine > Sent: Sunday, December 13, 2015 5:12 PM > To: Richard Henderson; gcc-patches@gcc.gnu.org > Cc: ja...@redhat.com; Matthew Fortune > Subject: RE: [RFA]

Re: [PATCH, PING*4] Track indirect calls for call site information in debug info.

On 12/02/2015 02:57 PM, Jakub Jelinek wrote: Ok, thanks. Great, thank you! I’ve pushed the change. -- Pierre-Marie de Rodat

Re: [PATCH, PING*4] Track indirect calls for call site information in debug info.

On 11/24/2015 06:10 PM, Jakub Jelinek wrote: The new pass is IMNSHO completely useless and undesirable, both for compile time (another whole IL traversal) reasons and for the unnecessary creation of memory allocations. Understood. Thank you very much for explaining how you think it should be!

Re: [PATCH, PING*4] Track indirect calls for call site information in debug info.

On Wed, Dec 02, 2015 at 02:46:28PM +0100, Pierre-Marie de Rodat wrote: > On 11/24/2015 06:10 PM, Jakub Jelinek wrote: > >The new pass is IMNSHO completely useless and undesirable, both for compile > >time (another whole IL traversal) reasons and for the unnecessary creation > >of memory

Re: [PATCH, PING*4] Track indirect calls for call site information in debug info.

Hello Jakub, On 11/24/2015 06:10 PM, Jakub Jelinek wrote: The new pass is IMNSHO completely useless and undesirable, both for compile time (another whole IL traversal) reasons and for the unnecessary creation of memory allocations. […] Thank you for your detailed answer! This is just to say

[PATCH] [ping] Add support for ARM embedded multilibs

Hello ! Did rebase the patch (sent at 11/08/2015 01:24 AM) to latest trunk (335ce86cb6cea8046993ab93d573316fd9ff798c). The patch is originally from Terry Guo (see https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00729.html). SVN commit r210320 on

Re: [PATCH, PING*4] PR debug/53927: fix value for DW_AT_static_link

Thank you Jason! On 11/25/2015 09:35 PM, Eric Botcazou wrote: We try to declare variables only at the first use point now I think. Fixed, thanks! + /* Debugging information needs to compute the frame base address of the +nestee frame out of the static chain from the nested

Re: [PATCH, PING*4] PR debug/53927: fix value for DW_AT_static_link

> Here’s the updated patch. Regtested again on x86_64-linux. Thanks, it looks good as far as I'm concerned (modulo the missing "in order" before "not to shift all other offsets" in a comment). -- Eric Botcazou

Re: [PATCH, PING*4] PR debug/53927: fix value for DW_AT_static_link

On 11/26/2015 03:50 PM, Eric Botcazou wrote: Here’s the updated patch. Regtested again on x86_64-linux. Thanks, it looks good as far as I'm concerned (modulo the missing "in order" before "not to shift all other offsets" in a comment). Fixed and pushed. Thank you again for reviewing! --

Re: [PATCH, PING*4] PR debug/53927: fix value for DW_AT_static_link

The DWARF change is OK if the tree-nested.c changes make sense to Eric. Jason

Re: [PATCH, PING*4] PR debug/53927: fix value for DW_AT_static_link

> The DWARF change is OK if the tree-nested.c changes make sense to Eric. As discussed in the audit trail of the PR, I'd rather have avoided the additional indirection, but the DWARF requirement seems to force it if we base the computation on the static chain and I don't see another approach.

Re: [PATCH, PING*4] Track indirect calls for call site information in debug info.

On Tue, Nov 24, 2015 at 05:31:11PM +0100, Pierre-Marie de Rodat wrote: > On 11/23/2015 10:11 PM, Jason Merrill wrote: > >Jakub, since DW_TAG_GNU_call_site is your feature, could you review this? > > As Jeff Law suggested in the “GCC 6 Status Report” thread, I’ve added > Alexandre Oliva to the

Re: [PATCH, PING*4] PR debug/53927: fix value for DW_AT_static_link

On 08/31/2015 09:28 AM, Pierre-Marie de Rodat wrote: Ping for the patch submitted in . As Jason noticed in another thread, I forgot to attach the patch here (although it’s filed in the bug tracker). Here it is! Rebased against trunk,

Re: [PATCH, PING*4] Track indirect calls for call site information in debug info.

On 11/23/2015 10:11 PM, Jason Merrill wrote: Jakub, since DW_TAG_GNU_call_site is your feature, could you review this? As Jeff Law suggested in the “GCC 6 Status Report” thread, I’ve added Alexandre Oliva to the discussion to review the var-tracking part. Also, I’ve

Re: [PATCH, PING*3] DWARF: materialize subprogram renamings in Ada as imported declarations

On 11/23/2015 10:00 PM, Jason Merrill wrote: DWARF changes are OK. The other changes are in the Ada front-end. Eric approved them offline already, so I’ve pushed them. By the way, a lot of changes were already merged by Arnaud Charlet a couple of days ago. Thank you both for the review!

Re: [PATCH, PING*3] DWARF: materialize subprogram renamings in Ada as imported declarations

On 08/31/2015 03:26 AM, Pierre-Marie de Rodat wrote: On 07/25/2015 09:44 PM, Pierre-Marie de Rodat wrote: This change makes GCC materialize subprogram renamings in Ada as imported declarations (DW_TAG_imported_declarations). For instance, procedure Foo renames Bar; will output:

Re: [PATCH, PING*4] Track indirect calls for call site information in debug info.

On 08/31/2015 03:28 AM, Pierre-Marie de Rodat wrote: On 07/20/2015 02:45 PM, Pierre-Marie de Rodat wrote: On PowerPC targets with -mlongcall, most subprogram calls are turned into indirect calls: the call target is read from a register even though it is compile-time known. This makes it

[PATCH][PING^2][C++] Fix PR67333

PING. On 08/27/2015 09:27 PM, Mikhail Maltsev wrote: > Hi. > This patch fixes a rejects-valid bug related to volatile-qualified arguments > of > constexpr functions. This is essentially a one-line change in constexpr.c. > Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for trunk? > >

Re: [PATCH] [ping] Use single shared memory block pool for all pool allocators

On 08/31/2015 02:44 PM, Richard Biener wrote: > Apart from Richards comments: > > +/* Return UNCAST_BLOCK to pool. */ > +inline void > +memory_block_pool::remove (void *uncast_block) > +{ > + block_list *block = reinterpret_cast (uncast_block); > + block->m_next = instance.m_blocks; > +

[PATCH][PING][C++] Fix PR67333

Ping. On 08/27/2015 09:27 PM, Mikhail Maltsev wrote: > Hi. > This patch fixes a rejects-valid bug related to volatile-qualified arguments > of > constexpr functions. This is essentially a one-line change in constexpr.c. > Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for trunk? > >

[PATCH, PING*3] PR rtl-optimization/66790: uninitialized registers handling in REE

On 07/19/2015 12:14 AM, Pierre-Marie de Rodat wrote: This patch is an attempt to fix PR rtl-optimization/66790: please see for the context. This adds a new dataflow problem (MIR for Must-Initialized Registers) and use it in the REE pass to

[PATCH, PING*3] DWARF: materialize subprogram renamings in Ada as imported declarations

On 07/25/2015 09:44 PM, Pierre-Marie de Rodat wrote: This change makes GCC materialize subprogram renamings in Ada as imported declarations (DW_TAG_imported_declarations). For instance, procedure Foo renames Bar; will output: DW_TAG_imported_declaration: DW_AT_name: foo

[PATCH, PING*4] Track indirect calls for call site information in debug info.

On 07/20/2015 02:45 PM, Pierre-Marie de Rodat wrote: On PowerPC targets with -mlongcall, most subprogram calls are turned into indirect calls: the call target is read from a register even though it is compile-time known. This makes it difficult for machine code static analysis engines to recover

[PATCH, PING*4] PR debug/53927: fix value for DW_AT_static_link

On 07/20/2015 09:39 AM, Pierre-Marie de Rodat wrote: This patch fixes the static link description in DWARF to comply with the specification. In order to do so, it appends a field to all FRAME objects to hold the frame base address (DW_AT_frame_base) so that the nested subrograms can directly

Re: [PATCH] [ping] Use single shared memory block pool for all pool allocators

On Mon, Aug 17, 2015 at 8:44 AM, Mikhail Maltsev wrote: > Hi, all. > I'm pinging this patch: > https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00030.html > > And adding some more changes to it (they are not complete yet - so they are > more > like an RFC). > In this patch I

Re: [PATCH] [ping] Use single shared memory block pool for all pool allocators

Mikhail Maltsev malts...@gmail.com writes: Hi, all. I'm pinging this patch: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00030.html A week and no reply, so FWIW: I really hope this goes in. malloc always shows up high in my profiles too. Just a couple of very minor things to show that I

Re: [PATCH] [PING] [PR libitm/61164] Remove redefinition of glibc internal macro __always_inline

On Mon, 2015-08-17 at 13:16 +0200, Gleb Fotengauer-Malinovskiy wrote: On Sun, Aug 16, 2015 at 07:35:17PM +0200, Torvald Riegel wrote: On Thu, 2015-06-11 at 14:36 +0300, Gleb Fotengauer-Malinovskiy wrote: On Fri, May 15, 2015 at 03:04:27PM +0200, Torvald Riegel wrote: On Wed, 2015-05-06

Re: [PATCH] [PING] [PR libitm/61164] Remove redefinition of glibc internal macro __always_inline

On Sun, Aug 16, 2015 at 07:35:17PM +0200, Torvald Riegel wrote: On Thu, 2015-06-11 at 14:36 +0300, Gleb Fotengauer-Malinovskiy wrote: On Fri, May 15, 2015 at 03:04:27PM +0200, Torvald Riegel wrote: On Wed, 2015-05-06 at 17:54 +0300, Gleb Fotengauer-Malinovskiy wrote: 2015-05-06 Gleb

[PATCH] [ping] Use single shared memory block pool for all pool allocators

Hi, all. I'm pinging this patch: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00030.html And adding some more changes to it (they are not complete yet - so they are more like an RFC). In this patch I also try to make obstacks use the same block pool as object pools. This seems rather easy to

Re: [PATCH] [PING] [PR libitm/61164] Remove redefinition of glibc internal macro __always_inline

On Thu, 2015-06-11 at 14:36 +0300, Gleb Fotengauer-Malinovskiy wrote: On Fri, May 15, 2015 at 03:04:27PM +0200, Torvald Riegel wrote: On Wed, 2015-05-06 at 17:54 +0300, Gleb Fotengauer-Malinovskiy wrote: 2015-05-06 Gleb Fotengauer-Malinovskiy gle...@altlinux.org PR libitm/61164

[PATCH, PING*2] PR rtl-optimization/66790: uninitialized registers handling in REE

On 07/19/2015 12:14 AM, Pierre-Marie de Rodat wrote: This patch is an attempt to fix PR rtl-optimization/66790: please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 for the context. This adds a new dataflow problem (MIR for Must-Initialized Registers) and use it in the REE pass to

[PATCH, PING*2] DWARF: materialize subprogram renamings in Ada as imported declarations

On 07/25/2015 09:44 PM, Pierre-Marie de Rodat wrote: This change makes GCC materialize subprogram renamings in Ada as imported declarations (DW_TAG_imported_declarations). For instance, procedure Foo renames Bar; will output: DW_TAG_imported_declaration: DW_AT_name: foo

[PATCH, PING*3] PR debug/53927: fix value for DW_AT_static_link

On 07/20/2015 09:39 AM, Pierre-Marie de Rodat wrote: This patch fixes the static link description in DWARF to comply with the specification. In order to do so, it appends a field to all FRAME objects to hold the frame base address (DW_AT_frame_base) so that the nested subrograms can directly

[PATCH, PING*3] Track indirect calls for call site information in debug info.

On 07/20/2015 02:45 PM, Pierre-Marie de Rodat wrote: On PowerPC targets with -mlongcall, most subprogram calls are turned into indirect calls: the call target is read from a register even though it is compile-time known. This makes it difficult for machine code static analysis engines to recover

[PATCH, PING*2] Track indirect calls for call site information in debug info.

On 07/20/2015 02:45 PM, Pierre-Marie de Rodat wrote: On PowerPC targets with -mlongcall, most subprogram calls are turned into indirect calls: the call target is read from a register even though it is compile-time known. This makes it difficult for machine code static analysis engines to recover

[PATCH, PING*2] PR debug/53927: fix value for DW_AT_static_link

On 07/20/2015 09:39 AM, Pierre-Marie de Rodat wrote: This patch fixes the static link description in DWARF to comply with the specification. In order to do so, it appends a field to all FRAME objects to hold the frame base address (DW_AT_frame_base) so that the nested subrograms can directly

[PATCH, PING] DWARF: materialize subprogram renamings in Ada as imported declarations

On 07/25/2015 09:44 PM, Pierre-Marie de Rodat wrote: This change makes GCC materialize subprogram renamings in Ada as imported declarations (DW_TAG_imported_declarations). For instance, procedure Foo renames Bar; will output: DW_TAG_imported_declaration: DW_AT_name: foo

[PATCH, PING] PR debug/53927: fix value for DW_AT_static_link

On 07/20/2015 09:39 AM, Pierre-Marie de Rodat wrote: This patch fixes the static link description in DWARF to comply with the specification. In order to do so, it appends a field to all FRAME objects to hold the frame base address (DW_AT_frame_base) so that the nested subrograms can directly

[PATCH, PING] Track indirect calls for call site information in debug info.

On 07/20/2015 02:45 PM, Pierre-Marie de Rodat wrote: On PowerPC targets with -mlongcall, most subprogram calls are turned into indirect calls: the call target is read from a register even though it is compile-time known. This makes it difficult for machine code static analysis engines to recover

[PATCH, PING] PR rtl-optimization/66790: uninitialized registers handling in REE

On 07/19/2015 12:14 AM, Pierre-Marie de Rodat wrote: This patch is an attempt to fix PR rtl-optimization/66790: please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 for the context. This adds a new dataflow problem (MIR for Must-Initialized Registers) and use it in the REE pass to

Re: [PATCH] [PING] [PR libitm/61164] Remove redefinition of glibc internal macro __always_inline

On Fri, May 15, 2015 at 03:04:27PM +0200, Torvald Riegel wrote: On Wed, 2015-05-06 at 17:54 +0300, Gleb Fotengauer-Malinovskiy wrote: 2015-05-06 Gleb Fotengauer-Malinovskiy gle...@altlinux.org PR libitm/61164 * local_atomic (__always_inline): Rename to...

RE: [PATCH, ping 1] Move insns without introducing new temporaries in loop2_invariant

Hello! From: Jeff Law [mailto:l...@redhat.com] Sent: Wednesday, May 13, 2015 4:05 AM OK for the trunk. Thanks for your patience, Thanks. Committed with the added PR rtl-optimization/64616 to both ChangeLog entries. This patch caused PR66236 [1]. [1]

Re: [PATCH][PING^2] Skip preprocessor directives in mklog

On Tue, May 12, 2015 at 11:50 AM, Tom de Vries tom_devr...@mentor.com wrote: I'm not a good choice to be the maintainer of a perl script. I'm all kinds of sorry about the original choice of scripting language. I'd just spend a couple of hours re-writing it in python.

Re: [PATCH][PING^2] Skip preprocessor directives in mklog

On 05/12/2015 06:57 PM, Trevor Saunders wrote: On Tue, May 12, 2015 at 06:33:28PM +0300, Yury Gribov wrote: On 05/12/2015 06:23 PM, Diego Novillo wrote: The patch looks fine to me. I'm not really involved in GCC development anymore. I would suggest that this script should be maintained by

Re: [PATCH, ping 1] Move insns without introducing new temporaries in loop2_invariant

On 05/12/2015 02:55 AM, Thomas Preud'homme wrote: From: Jeff Law [mailto:l...@redhat.com] Sent: Tuesday, May 12, 2015 4:17 AM On 05/06/2015 03:47 AM, Thomas Preud'homme wrote: Ping? Something to consider as future work -- I'm pretty sure PRE sets up the same kind of problematical pattern with

Re: [PATCH, ping 1] Move insns without introducing new temporaries in loop2_invariant

On 05/12/2015 03:32 AM, Thomas Preud'homme wrote: From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme From: Jeff Law [mailto:l...@redhat.com] Sent: Tuesday, May 12, 2015 4:17 AM + + /* Check that all uses reached by the def in insn

Re: [PATCH][PING^2] Skip preprocessor directives in mklog

On 05/12/2015 10:14 AM, Yury Gribov wrote: On 05/12/2015 06:57 PM, Trevor Saunders wrote: On Tue, May 12, 2015 at 06:33:28PM +0300, Yury Gribov wrote: On 05/12/2015 06:23 PM, Diego Novillo wrote: The patch looks fine to me. I'm not really involved in GCC development anymore. I would suggest

Re: [PATCH][PING^2] Skip preprocessor directives in mklog

On 05/12/2015 09:19 AM, Yury Gribov wrote: On 04/30/2015 12:03 PM, Yury Gribov wrote: On 04/21/2015 02:26 PM, Yury Gribov wrote: Hi all, Contrib/mklog is currently faked by preprocessor directives inside functions to produce invalid ChangeLog. The attached patch fixes this. Tested with my

RE: [PATCH, ping 1] Move insns without introducing new temporaries in loop2_invariant

From: Jeff Law [mailto:l...@redhat.com] Sent: Tuesday, May 12, 2015 4:17 AM On 05/06/2015 03:47 AM, Thomas Preud'homme wrote: Ping? Something to consider as future work -- I'm pretty sure PRE sets up the same kind of problematical pattern with a new pseudo (reaching reg) holding the

RE: [PATCH, ping 1] Move insns without introducing new temporaries in loop2_invariant

From: Jeff Law [mailto:l...@redhat.com] Sent: Wednesday, May 13, 2015 4:05 AM OK for the trunk. Thanks for your patience, Thanks. Committed with the added PR rtl-optimization/64616 to both ChangeLog entries. Best regards, Thomas

RE: [PATCH, ping 1] Move insns without introducing new temporaries in loop2_invariant

From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme From: Jeff Law [mailto:l...@redhat.com] Sent: Tuesday, May 12, 2015 4:17 AM + + /* Check that all uses reached by the def in insn would still be reached + it.

[PATCH][PING^2] Skip preprocessor directives in mklog

On 04/30/2015 12:03 PM, Yury Gribov wrote: On 04/21/2015 02:26 PM, Yury Gribov wrote: Hi all, Contrib/mklog is currently faked by preprocessor directives inside functions to produce invalid ChangeLog. The attached patch fixes this. Tested with my local mklog testsuite and

Re: [PATCH][PING^2] Skip preprocessor directives in mklog

The patch looks fine to me. I'm not really involved in GCC development anymore. I would suggest that this script should be maintained by whoever's been hacking on it the most. It's a simple script, so it shouldn't be hard to find a new maintainer for it. Diegop. On Tue, May 12, 2015 at 11:19

Re: [PATCH][PING^2] Skip preprocessor directives in mklog

On 05/12/2015 06:23 PM, Diego Novillo wrote: The patch looks fine to me. I'm not really involved in GCC development anymore. I would suggest that this script should be maintained by whoever's been hacking on it the most. It's a simple script, so it shouldn't be hard to find a new maintainer for

Re: [PATCH][PING^2] Skip preprocessor directives in mklog

On 12-05-15 17:33, Yury Gribov wrote: On 05/12/2015 06:23 PM, Diego Novillo wrote: The patch looks fine to me. I'm not really involved in GCC development anymore. I would suggest that this script should be maintained by whoever's been hacking on it the most. It's a simple script, so it

Re: [PATCH][PING^2] Skip preprocessor directives in mklog

On Tue, May 12, 2015 at 06:33:28PM +0300, Yury Gribov wrote: On 05/12/2015 06:23 PM, Diego Novillo wrote: The patch looks fine to me. I'm not really involved in GCC development anymore. I would suggest that this script should be maintained by whoever's been hacking on it the most. It's a

Re: [PATCH, ping 1] Move insns without introducing new temporaries in loop2_invariant

On 05/06/2015 03:47 AM, Thomas Preud'homme wrote: Ping? Something to consider as future work -- I'm pretty sure PRE sets up the same kind of problematical pattern with a new pseudo (reaching reg) holding the result of the redundant expression and the original evaluations turned into copies

RE: [PATCH, ping 1] Move insns without introducing new temporaries in loop2_invariant

Ping? Best regards, Thomas -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme Sent: Monday, March 16, 2015 8:39 PM To: 'Steven Bosscher' Cc: GCC Patches; Eric Botcazou Subject: RE: [PATCH, stage1] Move

Re: Patch ping

On 05/05/2015 08:52 PM, Jakub Jelinek wrote: Hi! http://gcc.gnu.org/ml/gcc-patches/2015-04/msg01432.html - this got approved for arm and aarch64, but not for s390{,x} Ok for trunk? Yes. Thanks! -Andreas-

Patch ping

Hi! http://gcc.gnu.org/ml/gcc-patches/2015-04/msg01432.html - this got approved for arm and aarch64, but not for s390{,x} Ok for trunk? Jakub

[PATCH][PING] Skip preprocessor directives in mklog

On 04/21/2015 02:26 PM, Yury Gribov wrote: Hi all, Contrib/mklog is currently faked by preprocessor directives inside functions to produce invalid ChangeLog. The attached patch fixes this. Tested with my local mklog testsuite and http://paste.debian.net/167999/ . Ok to commit?

Re: [PATCH,PING][ARM]Remove vec_shr and vec_shr optabs

On Tue, Apr 28, 2015 at 4:15 PM, Alan Lawrence alan.lawre...@arm.com wrote: No new code here ;). There is a slight change of execution path, i.e. some VEC_PERM_EXPRs (e.g. those for reductions via shifts) will be expanded using arm_expand_vec_perm_const rather than the vec_shr pattern. This

[PATCH,PING][ARM]Remove vec_shr and vec_shr optabs

No new code here ;). There is a slight change of execution path, i.e. some VEC_PERM_EXPRs (e.g. those for reductions via shifts) will be expanded using arm_expand_vec_perm_const rather than the vec_shr pattern. This generates EXT instructions equivalent to the original, but using the mode of the

Re: patch ping

On April 13, 2015 3:12:48 PM GMT+02:00, Jeff Law l...@redhat.com wrote: On 04/11/2015 04:27 PM, Bernhard Reutner-Fischer wrote: Hi, I'd like to ask an RM or global reviewer to kindly consider the following patches preventing one or the other target in config-list.mk to build: [PATCH, bfin]

Patch ping

Hi! I'd like to ping PR target/65689 - P2 - http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00358.html patch (perhaps with the code[?] == ' ' - ISSPACE (code[?]) changes or strstr, as discussed in the following thread). At this point of course for trunk only, and perhaps after a while for 5.2.

Re: Patch ping

On 06/02/14 12:12, Jakub Jelinek wrote: Hi! I'd like to ping a few outstanding patches: - PR59575 P1 ARM dwarf2cfi ICEs fix http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01997.html Wasn't this already approved (with comment fix)?

Re: Patch ping

On 17/04/15 16:46, Richard Earnshaw wrote: On 06/02/14 12:12, Jakub Jelinek wrote: Hi! I'd like to ping a few outstanding patches: - PR59575 P1 ARM dwarf2cfi ICEs fix http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01997.html Wasn't this already approved (with comment fix)?

Re: Patch ping

On 04/17/2015 01:59 AM, Jakub Jelinek wrote: Hi! I'd like to ping PR target/65689 - P2 - http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00358.html patch (perhaps with the code[?] == ' ' - ISSPACE (code[?]) changes or strstr, as discussed in the following thread). At this point of course for

[C++ PATCH PING] Reject trailing return type for operator auto()

On 28 December 2014 at 20:21, Ville Voutilainen ville.voutilai...@gmail.com wrote: Any comments on this? Re-ping. :) The original message is https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01614.html On 19 December 2014 at 09:21, Ville Voutilainen ville.voutilai...@gmail.com wrote: Tested on

Re: patch ping

On 04/11/2015 04:27 PM, Bernhard Reutner-Fischer wrote: Hi, I'd like to ask an RM or global reviewer to kindly consider the following patches preventing one or the other target in config-list.mk to build: [PATCH, bfin] handle BFIN_CPU_UNKNOWN in TARGET_CPU_CPP_BUILTINS

patch ping

Hi, I'd like to ask an RM or global reviewer to kindly consider the following patches preventing one or the other target in config-list.mk to build: [PATCH, bfin] handle BFIN_CPU_UNKNOWN in TARGET_CPU_CPP_BUILTINS https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00034.html [PATCH, c6x] handle

Patch ping

Hi! I'd like to ping following patch: PR65238 - P1 - http://gcc.gnu.org/ml/gcc-patches/2015-03/msg00647.html - fix __has_{,cpp_}attribute() with -traditional-cpp Thanks. Jakub

Re: Patch ping

On Wed, Feb 25, 2015 at 10:10:52AM +0100, Richard Biener wrote: Oops, totally forgot about this one. Shouldn't + default: + error (unsupported mode %s\n, mname); be a fatal_error ()? After all if we hit this but continue we'll Ok, I'll change it. stream random

Re: Patch ping

On Wed, 25 Feb 2015, Jakub Jelinek wrote: On Wed, Feb 18, 2015 at 11:00:35AM +0100, Jakub Jelinek wrote: On Tue, Feb 17, 2015 at 11:00:14AM +0100, Richard Biener wrote: I'm just looking for a way to make this less of a hack (and the LTO IL less target dependent). Not for GCC 5 for which

Patch ping

On Wed, Feb 18, 2015 at 11:00:35AM +0100, Jakub Jelinek wrote: On Tue, Feb 17, 2015 at 11:00:14AM +0100, Richard Biener wrote: I'm just looking for a way to make this less of a hack (and the LTO IL less target dependent). Not for GCC 5 for which something like your patch is probably ok,

Patch ping

Hi! I'd like to ping following patch: http://gcc.gnu.org/ml/gcc-patches/2015-02/msg00367.html - PR55541 - P2 - C++ debug info fix Thanks. Jakub

patch ping

Hi, I'd like to ping these patches http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02716.html pr 61889 - p1 don't require ftw.h in gcov-tool.c http://gcc.gnu.org/ml/gcc-patches/2015-01/msg01869.html pr 64076 - p2 - don't ICE on invalid code that has ironly and not ironly thunks thanks! Trev

Re: patch ping

Hi, I'd like to ping these patches http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02716.html pr 61889 - p1 don't require ftw.h in gcov-tool.c Looks good enough. Hopefully eventually someone will write mingw implementation. OK http://gcc.gnu.org/ml/gcc-patches/2015-01/msg01869.html pr

Patch ping

Hi! I'd like to ping 2 patches: http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02530.html - P2 - PR61925 - fix x86 #pragma GCC target handling http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02432.html - emit DW_LANG_Fortran{03,08} for -gdwarf-5 Jakub

<    1   2   3   4   5   6   7   8   9   10   >