Re: [PATCH, ping] zero-length arrays in OpenACC

Ping. Cesar On 06/01/2016 02:35 PM, Cesar Philippidis wrote: > This patch teaches c and c++ front ends and omp-low how to deal with > subarray involving GOMP_MAP_FORCE_{PRESENT,TO,FROM,TOFROM} data > mappings. As the libgomp test case shows, it might be possible for a > subarray to have zero leng

[PATCH PING] boehm-gc: check for execinfo.h directly

The current header depends on glibc version checks to determine whether execinfo.h exists which breaks uClibc. Instead, add an explicit configure check for it. 2015-08-29 Mike Frysinger * configure.ac: Call AC_CHECK_HEADERS([execinfo.h]). * configure: Regenerated. * in

Patch ping

Hi! I'd like to ping 3 XMM16+ patches: 1) avx_vec_concat http://gcc.gnu.org/ml/gcc-patches/2016-05/msg01826.html 2) *vec_concatv4si http://gcc.gnu.org/ml/gcc-patches/2016-05/msg02115.html 3) *vec_concatv2si_sse4_1 http://gcc.gnu.org/ml/gcc-patches/2016-05/msg02129.html Jakub

[C PATCH PING] PR43651: add warning for duplicate qualifier

On 04/10/2016 11:12 PM, Martin Sebor wrote: > On 04/09/2016 06:28 AM, Mikhail Maltsev wrote: >> On 04/08/2016 08:54 PM, Martin Sebor wrote: The name for new option "-Wduplicate-decl-specifier" and wording was chosen to match the same option in Clang. >>> >>> My version of Clang also warns

Patch ping

Hi! I'd like to ping a C++ PR70144 patch: http://gcc.gnu.org/ml/gcc-patches/2016-03/msg00653.html Since then, Zdenek has filed another PR with __builtin_constant_p (foo) where foo is FUNCTION_DECL, and only the above version fixes that, not the other one. Jakub

Re: Patch ping

OK. Jason

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 > awa

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 wh

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, Jane Smithard, Graha

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

OK. Jason

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 > > DECL_TEMPLATE_INSTA

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 http://gcc.gnu.org/ml/gcc-patches/2015-12/msg02

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 IC

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 DECL_TEMPLAT

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 (DECL_LANG_SP

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 23f8c38f593a

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] Compac

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 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 allocations

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.

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 th

[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 svn://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_9-

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! -- Pier

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

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 frame

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. A

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] 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 disc

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*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, b

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 rebased+bootstrapped+regt

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 difficul

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: DW_T

[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? > > gcc/c

[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? > > gcc/c

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; > + instan

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 also try to make obstac

[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 refe

[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*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 remo

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

Mikhail Maltsev 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 read the patch :-)

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, 201

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

[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 impl

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 > > > > > > PR libitm/61164 > > > *

[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*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 refe

[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*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 for the context. This adds a new dataflow problem (MIR for Must-Initialized Registers) and use it in the REE pass to remo

[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 refe

[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] 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 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 refe

[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 for the context. This adds a new dataflow problem (MIR for Must-Initialized Registers) and use it in the REE pass to remo

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 > > > > PR libitm/61164 > > * local_atomic (__always_inline): Rename to... > > (__libitm_always_inline):

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] https://gcc.gnu.org/bug

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^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 lo

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 wou

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 t

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^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 whoe

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

On Tue, May 12, 2015 at 11:50 AM, Tom de Vries 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 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.

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 shouldn'

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

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 AM

[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 http://paste.debian.

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 > > r

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

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 fro

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] M

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 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 generates >> EXT

[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 s

Re: patch ping

On April 13, 2015 3:12:48 PM GMT+02:00, Jeff Law 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]

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 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)? https://gcc.gnu.org/ml/gcc-patches/2014-02/msg003

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 tru

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.

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

On 28 December 2014 at 20:21, Ville Voutilainen 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 > wrote: >> Tested on Linux-x64. >> >> /cp >> 2014-12-19 Ville Voutila

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 https://gcc.gnu.org/ml/gc

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 unk_i

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 r

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