Re: [C++ PATCH] Implement new "force_static" attribute

On Mon, 1 Jul 2013, Gabriel Dos Reis wrote: On Mon, Jul 1, 2013 at 10:36 AM, David Malcolm wrote: My plan for removal of global variables in gcc 4.9 [1] calls for several hundred new classes, which will be singletons in a classic monolithic build, but have multiple instances in a shared-librar

Re: [C++ PATCH] Implement new "force_static" attribute

On Mon, Jul 1, 2013 at 10:36 AM, David Malcolm wrote: > My plan for removal of global variables in gcc 4.9 [1] calls for several > hundred new classes, which will be singletons in a classic monolithic > build, but have multiple instances in a shared-library build. > > In order to avoid the registe

[PATCH] [debug] Added DEBUG_FUNCTION void dump_backtrace.

* diagnostic-core.h: Declare dump_backtrace (void). * diagnostic.c: Define it. --- Just realized that I've submitted an unintended hunk in [PATCH 3/4] (http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00042.html). I didn't notice that I'd left a tracing line in 'gcc/cp/decl.c'. This

Re: [GOOGLE] use expand_location when checking same_line_p

This patch does not break the regression test. And because the final assembly is emitted with "expand_location" instead of "expand_location_to_spelling_point", thus when we check same_line_p, it should also reflect this. Dehao On Mon, Jul 1, 2013 at 4:28 PM, Cary Coutant wrote: >> This patch rep

[PATCH 4/4] [lambda] [polymorphic] [HACK] Avoid crash on symbol table writing when generic lambda declared with iostream (or potentially other code) included.

--- gcc/symtab.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/gcc/symtab.c b/gcc/symtab.c index 85d47a8..1ada0f7 100644 --- a/gcc/symtab.c +++ b/gcc/symtab.c @@ -116,6 +116,15 @@ insert_to_assembler_name_hash (symtab_node node, bool with_clones) tree name = DEC

Re: [GOOGLE] use expand_location when checking same_line_p

> This patch replaces expand_location_to_spelling_point with > expand_location so that macros will not be expanded. I'm confused. Doesn't this just undo the fix you made a month ago? How does this not break discriminator assignment? -cary

[PATCH 3/4] [lambda] [polymorphic] Infer template parameter from auto used in function parameter list.

--- gcc/cp/decl.c | 1 + gcc/cp/parser.c | 203 ++-- gcc/cp/pt.c | 7 ++ 3 files changed, 206 insertions(+), 5 deletions(-) diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c index 047fd77..00bcc35 100644 --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.

[PATCH 2/4] [lambda] [polymorphic] Support generic lambdas in templates.

--- gcc/cp/pt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 3847a1d..fbdd8ec6 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -18847,6 +18847,9 @@ instantiate_decl (tree d, int defer_ok, tree fn_context; bool nested; + if (TREE_CODE (d) == TEMPLATE

[C++14/lambda] Experimental polymorphic lambda patches

Hi all, I've finally reworked the generic lambda patches I made back in 2009 (http://gcc.1065356.n5.nabble.com/lambda-Latest-experimental-polymorphic-lambda-patches-tt713016.html) to apply against GCC's mainline. The syntaxes demonstrated by the following examples are supported (as per the previo

[PATCH 1/4] [lambda] [polymorphic] Support template-parameter-list in lambda-declarator.

--- gcc/cp/mangle.c| 2 ++ gcc/cp/parser.c| 43 +-- gcc/cp/semantics.c | 10 +- 3 files changed, 52 insertions(+), 3 deletions(-) diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c index 8da62b5..4d4c0fd 100644 --- a/gcc/cp/mangle.c +++ b/gcc/c

[GOOGLE] use expand_location when checking same_line_p

This patch replaces expand_location_to_spelling_point with expand_location so that macros will not be expanded. Bootstrapped and passed regression test. OK for google-4_8 branch? Thanks, Dehao Index: gcc/tree-cfg.c === --- gcc/tree

Re: [PATCH] if-to-switch pass

On 01/07/13 14:02, Tom de Vries wrote: >> > I also dislike the two passes being in early optimizations - that way they >> > do >> > not see the effects of IPA inlining / LTO IPA-CP transforms. >> > I'd rather move >> > it way down towards RTL expansion (though eventually some may say that >> > swi

Re: unordered containers: reuse nodes on assignment

On 07/01/2013 09:35 PM, François Dumont wrote: This is it indeed, I am surprised this problem is so old, a Standard issue perhaps ? If not I might add it to my todo list. Yesterday I had a look and I think it's just a bug, I found in Bugzilla a duplicate too, and another resolved Jon some time a

RE: [patch 2/4] fix -fstrict-volatile-bitfields bugs, v3

Hi Sandra, good work! I tested with arm-none-eabi. Now both variants, with and without -fstrict-volatile-bitfields produce the expected results for EABI-compliant structures, and still create reasonable code with non-compliant packed structures. > I think there is still a case where this ve

Re: [patch,i386] Cannot inline sse*.* functions into avx functions

On Mon, Jul 1, 2013 at 8:01 PM, Sriraman Tallam wrote: >So, something like the patch attached? > > * config/i386/i386.c (ix86_option_override_internal): Turn > on all -mavx target flags by default as they are dependent > on AVX anyway. Yes, but please also add: Index

[PATCH] [libatomic] Add --enable-werror.

libatomic is currently unconditionally built with -Werror. This patch adds --enable-werror to control it (enabled by default). Bootstrapped and tested on x86_64, and inspected build logs to ensure it was doing what it should. I'm assuming copyright assignment isn't necessary for a small change l

[PATCH] [libitm] Add --enable-werror.

libitm is currently unconditionally built with -Werror. This patch adds --enable-werror to control it (enabled by default). Bootstrapped and tested on x86_64, and inspected build logs to ensure it was doing what it should. I'm assuming copyright assignment isn't necessary for a small change like

Re: [c++-concepts] requires expression semantics

Updated with corrections for previous comments. New patch attached, but the Changelog is essentially the same. >> +/* A unary expression representing a requirement for an expression that >> + can be evaluated at compile time. */ > > Judging from the implementation, it seems that this relies on

Re: Remove global state from gcc/tracer.c

On 07/01/2013 12:59 PM, David Malcolm wrote: > I tried this approach for tracer, but there were non-trivial differences > between the old and new tracer.o files, enough to make me uncomfortable > with this approach. Like what? Are these just bugs in the IPA-CP pass failing to propagate? If so, w

Re: Remove global state from gcc/tracer.c

(restarting this thread: http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01318.html ) On Thu, 2013-05-23 at 13:51 -0700, Richard Henderson wrote: > On 05/23/2013 12:06 PM, Richard Henderson wrote: > > Another thing I should mention while you're doing all of these static > > function > > to class mem

Re: unordered containers: reuse nodes on assignment

This is it indeed, I am surprised this problem is so old, a Standard issue perhaps ? If not I might add it to my todo list. François On 06/30/2013 09:43 PM, Paolo Carlini wrote: .. looks like PR39269, but please double check. Paolo.

Re: [C++ PATCH] Implement new "force_static" attribute

On Mon, 2013-07-01 at 11:36 -0400, David Malcolm wrote: Sorry, I forgot the ChangeLog entries: gcc/ 2013-07-01 David Malcolm * doc/extend.texi (Type Attributes): Document new "force_static" attribute. gcc/cp/ 2013-07-01 David Malcolm * cp-tree.h (struct lang_type_

Re: [patch,i386] Cannot inline sse*.* functions into avx functions

Hi, So, something like the patch attached? * config/i386/i386.c (ix86_option_override_internal): Turn on all -mavx target flags by default as they are dependent on AVX anyway. Thanks Sri On Sun, Jun 30, 2013 at 2:56 AM, Uros Bizjak wrote: > On Sun, Jun 30, 2013 at

RE: [PATCH] Fix for PR c/57490

> -Original Message- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: Monday, July 01, 2013 1:09 PM > To: Iyer, Balaji V > Cc: gcc-patches@gcc.gnu.org; Rainer Orth > Subject: Re: [PATCH] Fix for PR c/57490 > > On Mon, Jul 01, 2013 at 05:02:57PM +, Iyer, Balaji V wrote: > > OK.

Re: [PATCH] Fix for PR c/57490

On Mon, Jul 01, 2013 at 05:02:57PM +, Iyer, Balaji V wrote: > > > > -Original Message- > > From: Jakub Jelinek [mailto:ja...@redhat.com] > > Sent: Monday, July 01, 2013 12:24 PM > > To: Iyer, Balaji V > > Cc: gcc-patches@gcc.gnu.org; Rainer Orth > > Subject: Re: [PATCH] Fix for PR c/5

Re: [PATCH] Fix for PR c/57490

On Mon, Jul 01, 2013 at 05:02:57PM +, Iyer, Balaji V wrote: > OK. The fixed patch is attached. Here are the ChangeLog entries: > > gcc/cp/ChangeLog > 2013-07-01 Balaji V. Iyer > Still PR c/57490 hasn't been added to cp/ChangeLog and c/ChangeLog entries. > --- /dev/null > +++ b/gcc

RE: [PATCH] Fix for PR c/57490

> -Original Message- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: Monday, July 01, 2013 12:24 PM > To: Iyer, Balaji V > Cc: gcc-patches@gcc.gnu.org; Rainer Orth > Subject: Re: [PATCH] Fix for PR c/57490 > > On Mon, Jul 01, 2013 at 04:17:37PM +, Iyer, Balaji V wrote: > > gc

Re: [PATCH] Fix for PR c/57490

On Mon, Jul 01, 2013 at 04:17:37PM +, Iyer, Balaji V wrote: > gcc/c/ChangeLog > +2013-07-01 Balaji V. Iyer > + The PR c/57490 line belongs to all ChangeLog entries related to the fix, not just testsuite. > + * c-array-notation.c (fix_conditional_array_notations_1): Added a > +

[v3] Update container::insert / emplace members to take const_iterator(s) (Part 3)

Hi, this is the last part (for now at least!), handling std::list and ext/vstring. Tested x86_64-linux, normal/debug/profile. Thanks, Paolo. / 2013-07-01 Paolo Carlini * include/bits/stl_list.h (list<>::insert(iterator, size_type, const value_type&

[PATCH] Fix for PR 57766

Hello Everyone, This patch will fix a buffer overflow issue in a test case shown in PR 57766. I am committing this patch as obvious. I am willing to revert (or modify) this patch if anyone has objections. Here is the ChangeLog entry: gcc/testsuite/ChangeLog +2013-07-01 Balaji V. Iyer

[PATCH] Fix for PR c/57490

Hello Everyone, This patch fixes the issue in PR 57490. The issue was that, the C and C++ implementation was not handling array notations inside TRUTH_*_EXPR. I added them and added the .i test case. Is this OK for trunk? Here are ChangeLog entries: gcc/c/ChangeLog +2013-07-01 Balaji

[C++ PATCH] Implement new "force_static" attribute

My plan for removal of global variables in gcc 4.9 [1] calls for several hundred new classes, which will be singletons in a classic monolithic build, but have multiple instances in a shared-library build. In order to avoid the register pressure of passing a redundant "this" pointer around for the

Re: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets

On 06/30/2013 09:32 PM, DJ Delorie wrote: Given how much trouble I went through to make it the default, I'd rather not revert all that work... especially since the flag is *required* for proper operation of the hardware on many of these targets. This patch will, or course, silently and obscure

[gomp4] Fix up #pragma omp declare simd parsing

Hi! The latest OpenMP 4.0 wording says: "The expressions appearing in the clauses of this directive are evaluated in the scope of the arguments of the function declaration or definition." so the current implementation of parsing all the clauses at the place where they appear and just don't lookup

Re: [PATCH] if-to-switch pass

On 24/06/13 14:28, Richard Biener wrote: > On Fri, Jun 21, 2013 at 10:37 PM, Cesar Philippidis > wrote: >> Here is an updated version of Tom's if-to-switch conversion pass that >> was originally posted here: >> >> . >> >> I corrected a build

Invitation to use Google Talk

--- You've been invited by Jagdish Rana to use Google Talk. If you already have a Google account, login to Gmail and accept this chat invitation: http://mail.google.com/mail/b-4c557a-713dcda8a3-rU29SiYot59QPn5-hwFBygcW9N0 To

RE: [PATCH][ARM] Fix FAIL pr46975

Hi Richard, > > This hurts code size. > > Therefore I've disabled the new peephole2 for optimize_insn_for_size_p > so that > > the original peephole before r200197 is used when optimising for size. > > > > I've also added a test to confirm that the new peephole2 for the non-CC > > setting variants

Re: [PATCH][2 of 2] RTL expansion for zero sign extension elimination with VRP

[Sorry for the delay] > For example, when an expression is evaluated and it's value is assigned > to variable of type short, the generated RTL would look something like > the following. > > (set (reg:SI 110) > (zero_extend:SI (subreg:HI (reg:SI 117) 0))) > > However, if during

Re: [ARM][Insn classification refactoring 3/N] Remove "wtype" attribute.

On 01/07/13 08:56, Sofiane Naci wrote: Hi, This patch is the part of the ongoing work of ARM instruction classification cleanup. This patch moves the Wireless MMX instruction classification into the "type" attribute, and removes the "wtype" attribute. This has been tested with a full arm-none-

[Patch, Fortran] PR57469 - silence unused dummy arg warning, if it is used in a namelist

Built and regtested on x86-64-gnu-linux. OK for the trunk? Tobias 2013-07-01 Tobias Burnus PR fortran/57469 * trans-decl.c (generate_local_decl): Don't warn that a dummy is unused, when it is in a namelist. 2013-07-01 Tobias Burnus PR fortran/57469 * gfortran.dg/warn_unused_dummy_ar

[Fortran] Patch ping

The following patches are pending to be reviewed: * http://gcc.gnu.org/ml/fortran/2013-06/msg00142.html * http://gcc.gnu.org/ml/fortran/2013-06/msg00141.html * http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html * http://gcc.gnu.org/ml/fortran/2013-06/msg00137.html * http://gcc.gnu.org/ml/fortran

Re: [PATCH] Caller instrumentation with -finstrument-calls

Hi Andrew, On Friday 28 June 2013 09:50:31 Andrew Pinski wrote: > On Fri, Jun 28, 2013 at 5:51 AM, wrote: > > Hi, > > > > The patch below provides caller instrumentation for GCC. > > > > The following new options have been added: > > -finstrument-calls > > -finstrument-calls-exclude-fu

Re: [Patch, Fortran] PR54788 ICE on pointer-array element assignment

Am 28.06.2013 17:03, schrieb Dominique Dhumieres: The following patchlet fixes the ICE for the test case bellow and AFAICT gives the right error. Regstrapped on x86_64-apple-darwin10.8.0. OK for the trunk? The patch is okay and sufficiently trivial. Committed as Rev. 200575. Thanks for the pa

Re: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets

On Sun, Jun 30, 2013 at 8:32 PM, DJ Delorie wrote: > > Given how much trouble I went through to make it the default, I'd > rather not revert all that work... especially since the flag is > *required* for proper operation of the hardware on many of these > targets. > > This patch will, or course,