C++ PATCH for c++/49172 (allow constexpr reference variables)

We decided at the Madrid meeting to allow constexpr reference variables, and this patch adds that support to GCC. Tested x86_64-pc-linux-gnu, applying to trunk. commit 02d12daad9a5d1b265a328e43d758d9eedd9bb04 Author: Jason Merrill Date: Tue Jun 21 22:24:29 2011 -0400 PR c++/49172 *

Regression with "varpool alias reorg"

On Sat, 18 Jun 2011, Jan Hubicka wrote: > * lto-symtab.c (lto_varpool_replace_node): Remove code handling > extra name aliases. > (lto_symtab_resolve_can_prevail_p): Likewise. > (lto_symtab_merge_cgraph_nodes): Update alias_of pointers. > * cgraphbuild.c (record_refer

Re: Improve jump threading #5 of N

On Wed, 15 Jun 2011, Jeff Law wrote: > So as I've mentioned previously, I've been working on a relatively small > change to the jump threading code which would allow it to duplicate a > join block when doing so allows us to thread through a successor of the > join block. This is expected to be the

Re: [Patch, AVR]: Fix PR46779

On Mon, 13 Jun 2011, Georg-Johann Lay wrote: > [In CCing Richard Henderson] > Denis Chertykov schrieb: > > 2011/6/10 Georg-Johann Lay : > > > Then I observed trouble with DI patterns during libgcc build and had > > > to remove > > > > > > * "zero_extendqidi2" > > > * "zero_extendhidi2" > > > * "ze

Re: Patch: speed up compiler a little bit by optimizing lookup_attribute() and is_attribute_p()

Ok, here's a revised patch (contextual diff, as requested). The inline code is now minimized to the "hot" stuff, as discussed. In benchmarks this arrangement performs a tiny bit slightly better than the previous patch, so that's great news. :-) Bootstrapped on GNU/Linux i686, regression tested.

Re: __sync_swap* [ rename sync builtins ]

On 06/21/2011 07:03 PM, Andrew MacLeod wrote: On 06/21/2011 06:26 PM, Graham Stott wrote: All --- On Tue, 21/6/11, Richard Henderson wrote: This looks to have broken the go frontend Graham ah, missed it's .cc file, and I guess it doesn't build by default :-P This ought to fix it, checkin

Re: [PATCH, ARM] VSHL, VSHR, VLSHR immediate values support

> > Please get approval for the target independent parts (changes to > optabs.c) separately from a middle-end maintainer.  I cannot approve > those bits. Can a global reviewer take a look at the non-target specific changes http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00191.html cheers Ramana

Clean up TARGET_ASM_NAMED_SECTION defaults

I noted in the fragile nature of the default of TARGET_HAVE_NAMED_SECTIONS based on TARGET_ASM_NAMED_SECTION (relying on (a) TARGET_ASM_NAMED_SECTION being defined in tm.h not a .c file and (b) the order in which headers are included). This

Re: __sync_swap* [ rename sync builtins ]

On 06/21/2011 06:26 PM, Graham Stott wrote: All --- On Tue, 21/6/11, Richard Henderson wrote: This looks to have broken the go frontend gcc/gcc/go/gofrontend/gogo-tree.cc: In member function ‘void Gogo::define_builtin_function_trees()’: /usr/local/src/gcc4.7/gcc/gcc/go/gofrontend/gogo-tree.c

[v3] Use noexcept in array swap

Hi, tested x86_64-linux, committed. Paolo. /// 2011-06-22 Daniel Krugler Paolo Carlini * include/bits/move.h (__is_nothrow_swappable): Add. (swap(_Tp(&)[_Nm], _Tp(&)[_Nm])): Use noexcept. * include/bits/algorithmfwd.h: Adjust.

[cxx-mem-model] sync_mem_exchange implementation with memory model parameters

OK, I've brought the cxx-mem-model branch up to mainline as of this afternoon. (After I applied the patch which renamed all the mis-named _sync expanders) So this is the marginally reworked patch we had before which I think satisfies all the requests I've seen. Bootstraps and no regerssions

Re: __sync_swap* [ rename sync builtins ]

All --- On Tue, 21/6/11, Richard Henderson wrote: > From: Richard Henderson > Subject: Re: __sync_swap* [ rename sync builtins ] > To: "Andrew MacLeod" > Cc: "Aldy Hernandez" , "Jakub Jelinek" , > "Joseph S. Myers" , "gcc-patches" > > Date: Tuesday, 21 June, 2011, 19:50 > On 06/21/2011 11:

[testsuite] ARM: don't specify unneeded -march

I modified these tests last week to check for thumb support and to ignore messages about conflicting options, but -march isn't needed and so there shouldn't be any conflicting options. OK? 2011-06-21 Janis Johnson * gcc.target/arm/pr45701-1.c: Don't specify -march; remove dg-pr

Re: [testsuite] ARM: require arm_thumb2_ok, drop -march

On 21 June 2011 22:06, Janis Johnson wrote: > Modify three tests that require thumb2 support to check for that rather > than specifying an arch value that might be overridden by multilib flags. > > OK for trunk, and later for 4.6? OK - this is a nice cleanup. Ramana >

Re: [testsuite] ARM: remove -march from tests that don't need it

On 06/21/2011 02:25 PM, Ramana Radhakrishnan wrote: > On 21 June 2011 22:04, Janis Johnson wrote: >> This patch removes "-march=armv7-a" from four tests that pass with all >> -march values from armv4t on. >> >> OK for trunk? >> > > No, that sounds like a bug - if we are generating smlaltb and fri

Re: [testsuite] ARM: check for thumb1 or thumb2 support

On 21 June 2011 22:07, Janis Johnson wrote: > Modify three tests that require thumb support by skipping them if > neither thumb1 nor thumb2 is supported. > > OK for trunk, and later for 4.6? > Ok Thanks, Ramana

Re: [testsuite] ARM: remove -march from tests that don't need it

On 21 June 2011 22:04, Janis Johnson wrote: > This patch removes "-march=armv7-a" from four tests that pass with all > -march values from armv4t on. > > OK for trunk? > No, that sounds like a bug - if we are generating smlaltb and friends for v4t then the compiler is broken. This is probably beca

[testsuite] ARM: check for thumb1 or thumb2 support

Modify three tests that require thumb support by skipping them if neither thumb1 nor thumb2 is supported. OK for trunk, and later for 4.6? 2011-06-21 Janis Johnson * gcc.target/arm/20031108-1.c: Require thumb1 or thumb2. * gcc.target/arm/pr40482.c: Likewise. * gcc.targe

[testsuite] ARM: require arm_thumb2_ok, drop -march

Modify three tests that require thumb2 support to check for that rather than specifying an arch value that might be overridden by multilib flags. OK for trunk, and later for 4.6? 2011-06-21 Janis Johnson * gcc.target/arm/ctz.c: Don't specify -march, require thumb2. * gc

[testsuite] ARM: require arm_thumb1_ok, drop -march

This test requires thumb1, so skip it for targets that don't support that instead of specifying an arch value that might be overridden by multilib flags. OK for trunk, and later for 4.6? 2011-06-21 Janis Johnson * gcc.target/arm/thumb-bitfld1.c: Don't specify -march, require thumb1. I

[testsuite] ARM: remove -march from tests that don't need it

This patch removes "-march=armv7-a" from four tests that pass with all -march values from armv4t on. OK for trunk? 2011-06-21 Janis Johnson * gcc.target/arm/smlaltb-1.c: Don't specify -march. * gcc.target/arm/smlaltt-1.c: Likewise. * gcc.target/arm/smlatb-1.c: Likewise.

[testsuite] ARM: adjust skips for Xscale test

This patch allows an Xscale-specific test to run if multilib flags include -march=xscale and to be skipped if -mcpu= is used with anything besides xscale. OK for trunk, and later for 4.6? 2011-06-21 Janis Johnson * gcc.target/arm/scd42-3.c: Allow -march-xscale; skip if -mcpu is

[testsuite] dg-require-effective-target: skip unneeded checks

This patch causes dg-require-effective-target to return early if the test is already being skipped, saving some work. There's already similar code in dg-skip-if. OK for trunk, and later for 4.6? 2011-06-21 Janis Johnson * lib/target-supports-dg.exp (dg-require-effective-target): Retur

Fix ACATS c94007a on 4.6 branch for SPARC64/Solaris

This is the failure of ACATS c94007a at -O2 on SPARC64/Solaris: the compiler generates wrong code because of a delay slot scheduling (reorg.c) bug. This is a regression on the 4.6 branch (4.5 branch and mainline are clean). fill_simple_delay_slots decides to fill the delay slot of a call insn wit

Re: [pph] Reorganize pph read/write file into their respective streamers (issue4657042)

Note: There might now be unused headers in pph.c (although I didn't need to add any headers to the streamers, so it would have to be one of the headers they all use). http://codereview.appspot.com/4657042/

C++ PATCH for c++/49482 (bogus set but not used parameter warning with lambda)

When we are building up a call by hand at low level, apparently we need to explicitly mark the arguments as read. Or unset TREE_USED, I suppose, but they are in fact read. Tested x86_64-pc-linux-gnu, applied to trunk and 4.6.1. commit dec88b99a5f96603df3518da6b108e058613bc2d Author: jason Dat

Re: [PATCH] Middle-end arrays, forward-ported to trunk (again)

On Tuesday 21 June 2011 17:08:17 Richard Guenther wrote: > The following is a patch^Whack that should handle almost all > array exprs. Well, tried on the following testcase: > > subroutine foo (dst, bar, ni, nj) > integer, intent(in) :: ni, nj > double precision, intent(in) :: bar(ni, nj) >

C++ PATCH for c++/49418 (lost cv-quals on template parameter type)

cv-qualifiers are dropped from a function parameter type in order to produce the parameter-type-list, but the parameter itself still has the qualified type within the function body. When I added cv-qualification stripping to type_decays_to, it started affecting instantiation of template functi

[pph] Reorganize pph read/write file into their respective streamers (issue4657042)

Avoid exposing more and more streamer functions in the headers by moving all the read logic to pph-streamer-in.c and the write logic to pph-streamer-out.c This is a pure copy/paste of the functions, no new functionality was added in this patch Tested with bootstrap build and pph regression testi

Re: __sync_swap* [ rename sync builtins ]

On 06/21/2011 11:46 AM, Andrew MacLeod wrote: > * c-family/c-common.c: Add sync_ or SYNC__ to builtin names. > * c-family/c-omp.c: Add sync_ or SYNC__ to builtin names. > * java/builtins.c: Add sync_ or SYNC__ to builtin names. > * java/expr.c: Add sync_ or SYNC__ to builtin

Re: [pph contrib] Add support for multiple spawn patterns in repro_fail (issue4571061)

On Jun 10, 2011, dnovi...@google.com (Diego Novillo) wrote: > I'm thinking that this script is better written in python, but that > may make it less generic and I don't know whether we accept python in > gcc/contrib. Alex? I guess anything goes in gcc/contrib, so it could be rewritten in Python,

Re: [PATCH] Middle-end arrays, forward-ported to trunk (again)

Dear Richi, The point of entry for assignments is in trans-expr.c 06038 tree 06039 gfc_trans_assignment (gfc_expr * expr1, gfc_expr * expr2, bool init_flag, 06040 bool dealloc) 06041 { a bunch of special cases 06088 06089 /* Fallback to the scalarizer to generate

Re: Patch ping

On 06/19/2011 11:41 PM, Jakub Jelinek wrote: > [debug] > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00649.html > trunk only > DW_OP_GNU_parameter_ref support > > [debug] > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00751.html > trunk only > DW_OP_GNU_convert <0> support Both ok.

Re: [PATCH, MELT] fix minor issue with meltgc_new_split_string

Thanks. I applied both patches: % svn log --limit 2 gcc/melt-runtime.c r175268 | bstarynk | 2011-06-21 19:29:34 +0200 (Tue, 21 Jun 2011) | 6 lines 2011-06-21 Pierre Vittet * melt-runtime.c (meltgc_new_split_stri

Re: [ARM] TLS Descriptor support

> revalidated with defaults to both gnu and gnu2 style. ok? This is OK . Ramana > > nathan > -- > Nathan Sidwell > >

Re: [Patch, AVR]: Fix PR33049 (implement extzv)

2011/6/21 Georg-Johann Lay : > Denis Chertykov schrieb: > >> I'm vote for 'C'. >> >> Denis. > > So it's C :-) > > Johann > >        PR target/33049 >        * config/avr/avr.md (extzv): New expander. >        (*extzv): New insn. >        (*extzv.qihi1, *extzv.qihi2): New insn-and-split. >        *

Re: [libjava] Fix md5test, shatest on Tru64 UNIX with native libiconv (PR libgcj/49314)

On 06/21/2011 02:55 PM, Rainer Orth wrote: > As described in the PR, unless the UTF-8 encoding of \ufeff is padded > with a NUL byte, the iconv_init test fails for the native Tru64 UNIX > libiconv, iconv_byte_swap isn't set correctly and later iconv calls > fail. This patch fixes this, allowing th

Re: [Patch, AVR]: Fix PR46779

Do you think we can split the patch intended to fix PR46779 > PR target/46779 > * config/avr/avr.c (avr_hard_regno_mode_ok): Rewrite. > In particular, allow 8-bit values in r28 and r29. > (avr_hard_regno_scratch_ok): Disallow any register that might be > part of the f

Re: [PATCH, ARM] iWMMXT maintenance

Joseph S. Myers wrote: > On Mon, 20 Jun 2011, Xinyu Qi wrote: > >> *gcc/config/arm/elf.h: Add option -mwmmxt. >> *gcc/config/arm/arm.opt: Same. > > Why? And where are the documentation updates? How does this relate to > the existing iWMMXt options? > > I thought the plan (Ramana?) was to move to

[PATCH] Handle __builtin*chk and other builtins in various spots

Hi! While working on __builtin_assume_aligned support, I've noticed a bunch of places which handle some builtins specially in CCP/DCE/aliasing, but don't handle other similar calls. Additionally in CCP for stringops that just return its first argument we can use first arguments properties for the

Re: [Patch, AVR]: Fix PR33049 (implement extzv)

Denis Chertykov schrieb: > I'm vote for 'C'. > > Denis. So it's C :-) Johann PR target/33049 * config/avr/avr.md (extzv): New expander. (*extzv): New insn. (*extzv.qihi1, *extzv.qihi2): New insn-and-split. * config/avr/constraints.md (C04): New constrain

Re: [PATCH] Fix __bultin_clrsb* (PR middle-end/49489)

On 06/21/2011 06:10 PM, Jakub Jelinek wrote: > gcc.c-torture/execute/builtin-bitops-1.c fails on x86_64-linux, because > there is no SImode libcall, only DImode, and it was zero-extending instead > of sign-extending the argument, and not subtracting the mode difference > afterwards. So int foo (in

[PATCH] Fix __bultin_clrsb* (PR middle-end/49489)

On Mon, Jun 20, 2011 at 09:38:22PM +0200, Bernd Schmidt wrote: > On 06/16/2011 06:25 PM, Richard Henderson wrote: > > On 06/16/2011 05:44 AM, Bernd Schmidt wrote: > >> +@deftypefn {Built-in Function} int __builtin_clrsb (unsigned int x) > >> +Returns the number of leading redundant sign bits in @va

[PATCH, MELT] fix minor issue with meltgc_new_split_string

Hello, I got a bug when using meltgc_new_split_string (in melt-runtime.c) with a string (argument str) like this one "mystringanotherString" with the separator. The function is not working on a string that start with the separator. I guess this case can happen in real case, for exemple when a

Re: SRA generates uninitialized var use

On Tue, Jun 21, 2011 at 5:51 PM, Xinliang David Li wrote: > On Tue, Jun 21, 2011 at 1:42 AM, Richard Guenther > wrote: >> On Tue, Jun 21, 2011 at 1:28 AM, Xinliang David Li >> wrote: >>> Good point -- but why does SRA have to be so complicated? If it just >>> do structure expansion and let subs

Re: SRA generates uninitialized var use

On Tue, Jun 21, 2011 at 1:42 AM, Richard Guenther wrote: > On Tue, Jun 21, 2011 at 1:28 AM, Xinliang David Li wrote: >> Good point -- but why does SRA have to be so complicated? If it just >> do structure expansion and let subsequent phases to clean it up, would >> it be simpler? Anyway this is o

Re: [PATCH] middle-end only piece of middle-end array expressions

On Tue, 21 Jun 2011, Richard Guenther wrote: > > This is the middle-end pieces, without the C/C++ frontend changes. > Enough to work on the Fortran parts. > > Doesn't even break bootstrap. And here is a variant that doesn't need the tree-cfg.c hunk for the Fortran patch (thus all type problems

Re: Patch: speed up compiler a little bit by optimizing lookup_attribute() and is_attribute_p()

On Tue, Jun 21, 2011 at 3:39 PM, Dimitrios Apostolou wrote: > Hi Nicola, > > my patch is too simple compared to yours, feel free to work on it as much as > you wish, no need to credit me since you posted it independantly. I just > posted it to note that the inlining part is the one providing most

[PATCH] middle-end only piece of middle-end array expressions

This is the middle-end pieces, without the C/C++ frontend changes. Enough to work on the Fortran parts. Doesn't even break bootstrap. Richard. 2008-04-11 Richard Guenther * builtin-attrs.def (ATTR_COVARIANTRETURN): Add. (ATTR_NOTHROW_TYPEGENERIC): Likewise. (ATTR_NOT

Re: [PATCH] Middle-end arrays, forward-ported to trunk (again)

On Tue, 21 Jun 2011, Richard Guenther wrote: > > This forward-ports the middle-end array patch. Patch status is the > same as with the last forward-port from 2009 - the scalarizer cannot > deal with control flow and it cannot insert temporaries when > required (so it operates in a mode that requ

Re: Unreviewed libgcc build patch

Paolo Bonzini writes: > Ok without the commented info evaluation, and with the per-target > macro renamed to c_flags-$<. Here's what I've installed after rebuilding libgcc and verifying that -fexceptions still isn't applied to enable-execute-stack.c. Thanks. Rainer 2011-06-21 Rainer

Re: Unreviewed libgcc build patch

Ok without the commented info evaluation, and with the per-target macro renamed to c_flags-$<. Thanks, Paolo 2011/6/20, Rainer Orth : > The following patch > > [build, libgcc] Correctly apply c_flags in shared-object.mk > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01055.html > >

[libjava] Fix md5test, shatest on Tru64 UNIX with native libiconv (PR libgcj/49314)

As described in the PR, unless the UTF-8 encoding of \ufeff is padded with a NUL byte, the iconv_init test fails for the native Tru64 UNIX libiconv, iconv_byte_swap isn't set correctly and later iconv calls fail. This patch fixes this, allowing the arraycopy testcase in the PR and the actual md5te

Rename across basic block boundaries

This patch requires http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02193.html as a prerequisite, and supersedes http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02194.html The idea here is to allow regrename to operate across basic block boundaries. This helps for targets that use sched_ebb (such as

Re: Patch: speed up compiler a little bit by optimizing lookup_attribute() and is_attribute_p()

Hi Nicola, my patch is too simple compared to yours, feel free to work on it as much as you wish, no need to credit me since you posted it independantly. I just posted it to note that the inlining part is the one providing most performance benefit. richi: I used always_inline because it is t

Generic hwloop support library

We currently support counted loops on several targets by having the loop-doloop pass search for suitable loops and convert them to using the doloop_end pattern. Unfortunately, there are various machines which have hardware loop support, but need additional tests and transformations, during the fina

Re: Patch: speed up compiler a little bit by optimizing lookup_attribute() and is_attribute_p()

Dimitrious I didn't realize you were working on this. Your patch is indeed very similar. :-) Can I go ahead and rewrite mine following Richard's suggestions (which would make it even more similar to yours), and add your name to the ChangeLog entry too ? Thanks On 21 Jun 2011, at 13:20, Dimit

Re: [Patch, AVR]: Fix build warning in md.

2011/6/21 Georg-Johann Lay : > gen machinery comes up with a build warning: > > ../../../gcc.gnu.org/trunk/gcc/config/avr/avr.md:2763: '@' is > redundant for output template with single alternative > > There is @ asm template selector for insn with just one alternative. > > This trivial patch fixes

Re: [Patch, AVR]: Fix PR33049 (implement extzv)

2011/6/21 Georg-Johann Lay : > Denis Chertykov schrieb: >> 2011/6/21 Georg-Johann Lay: > >>> Ok.  d_register_operand or satisfies_constraint_d would do.  But I >>> preferred to introduce a new constraint for 4 and avoid splitting >>> *extzv altogether to keep it simple.  Complexity of splitting is

Re: [Patch, AVR]: Fix PR33049 (implement extzv)

Denis Chertykov schrieb: > 2011/6/21 Georg-Johann Lay: >> Ok. d_register_operand or satisfies_constraint_d would do. But I >> preferred to introduce a new constraint for 4 and avoid splitting >> *extzv altogether to keep it simple. Complexity of splitting is not a >> real advantage over writing

Re: Patch: speed up compiler a little bit by optimizing lookup_attribute() and is_attribute_p()

On Tue, Jun 21, 2011 at 2:20 PM, Dimitrios Apostolou wrote: > FWIW I think that most of the speedup is due to inlining lookup_attribute(). > I got almost the same by applying only the attached very simple patch, since > strlen() was called too often (according to the profile at [1]). I used the >

Re: [Patch, Fortran, OOP] PR 49112: [4.6/4.7 Regression] Missing type-bound procedure, "duplicate save" warnings and internal compiler error

2011/6/21 Jakub Jelinek : > On Tue, Jun 21, 2011 at 12:29:01AM +0200, Janus Weil wrote: >> However, I would also like to apply it to the 4.6 branch (which was >> frozen a few hours ago). Is there any chance to get approval by the >> RM's for this? > > Yeah, it looks small and safe enough for 4.6.1

Re: Patch: speed up compiler a little bit by optimizing lookup_attribute() and is_attribute_p()

FWIW I think that most of the speedup is due to inlining lookup_attribute(). I got almost the same by applying only the attached very simple patch, since strlen() was called too often (according to the profile at [1]). I used the always_inline attribute to avoid using a macro. I was going to

[patch] Fix PR tree-optimization/49478

Hi, This patch adds a missing support of widening multiplication by a constant in case of DOT_PROD_EXPR: the type of the constant operand should be set according to the other operand. Bootstrapped and tested on powerpc64-suse-linux. Committed. Ira ChangeLog: PR tree-optimization/49478 *

Re: [Patch, AVR]: Fix PR33049 (implement extzv)

2011/6/21 Georg-Johann Lay : > Denis Chertykov schrieb: >> 2011/6/20 Georg-Johann Lay : >>> This is an optimization patch that implements extzv for 1-bit extracts. >> >> >>> +(define_insn_and_split "*extzv" >>> +  [(set (match_operand:QI 0 "register_operand"                     >>> "=*d,*d,*d,r") >

Re: [PATH] PR/49139 fix always_inline failures diagnostics

On Tue, Jun 21, 2011 at 1:11 PM, Richard Guenther wrote: > On Mon, Jun 20, 2011 at 3:56 PM, Christian Bruel > wrote: >> On 06/20/2011 03:41 PM, Rainer Orth wrote: >>> >>> Christian Bruel  writes: >>> 2011-06-16  Christian Bruel        PR 49139/43654 >>> >>> Please use the correct

[Patch, AVR]: Fix build warning in md.

gen machinery comes up with a build warning: ../../../gcc.gnu.org/trunk/gcc/config/avr/avr.md:2763: '@' is redundant for output template with single alternative There is @ asm template selector for insn with just one alternative. This trivial patch fixes that. Johann * config/avr/avr.m

Re: [PATH] PR/49139 fix always_inline failures diagnostics

On Mon, Jun 20, 2011 at 3:56 PM, Christian Bruel wrote: > On 06/20/2011 03:41 PM, Rainer Orth wrote: >> >> Christian Bruel  writes: >> >>> 2011-06-16  Christian Bruel >>> >>>        PR 49139/43654 >> >> Please use the correct PR number format here: >> >>        PR middle-end/49139 >>         PR mi

[PATCH] Fix PR49483

This fixes a missed vectorization with bitwise int-float conversions. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2011-06-21 Richard Guenther PR tree-optimization/49483 * tree-vect-stmts.c (vectorizable_assignment): Also handle VIE

Re: Patch: speed up compiler a little bit by optimizing lookup_attribute() and is_attribute_p()

On Tue, Jun 21, 2011 at 12:17 PM, Nicola Pero wrote: >>> This patch speeds up the C/C++/ObjC/ObjC++ compiler a little bit by >>> optimizing >>> lookup_attribute() and is_attribute_p().  The main change is that these >>> functions >>> are now inline. >> >> I don't think this is a good idea. > > C

Re: Patch: speed up compiler a little bit by optimizing lookup_attribute() and is_attribute_p()

>> This patch speeds up the C/C++/ObjC/ObjC++ compiler a little bit by >> optimizing >> lookup_attribute() and is_attribute_p().  The main change is that these >> functions >> are now inline. > > I don't think this is a good idea. Can you explain why ? You never do in your response :-) I'm gue

Re: [PATCH, ARM] iWMMXT maintenance

On Mon, 20 Jun 2011, Xinyu Qi wrote: > *gcc/config/arm/elf.h: Add option -mwmmxt. > *gcc/config/arm/arm.opt: Same. Why? And where are the documentation updates? How does this relate to the existing iWMMXt options? I thought the plan (Ramana?) was to move to having a -msimd= option to select

[patch] Include tags file for generated source files

Hi, This small patch build and include tags file for generated source files under $(objdir). This is helpful to browse source files using TAGS. Tested on my i686-pc-linux-gnu machine. Is it OK? Thanks, Mingjie 2011-06-21 Mingjie Xing * Makefile.in (TAGS): Add new object obj.tags,

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

Hi Thomas, > (Sorry for being late with this -- I'm listed as a GNU/Hurd OS Port > Maintainer, but I have not been CCed in the original patch email, and I'm > only able to read gcc-patches/the Git log at irregular times.) sorry for not including you in the Cc: I must have simply overlooked it and

Re: [Patch, AVR]: Fix PR33049 (implement extzv)

Denis Chertykov schrieb: > 2011/6/20 Georg-Johann Lay : >> This is an optimization patch that implements extzv for 1-bit extracts. > > >> +(define_insn_and_split "*extzv" >> + [(set (match_operand:QI 0 "register_operand" >> "=*d,*d,*d,r") >> +(zero_extract:QI (match_o

Re: Simplify Solaris configuration

> Bootstrapped without regressions on i386-pc-solaris2.11 (Sun as/ld, GNU > as/Sun ld, GNU as, ld), i386-pc-solaris2.10 (Sun as/ld), and > sparc-sun-solaris2.11 (Sun as/ld) so far. Bootstraps on > i386-pc-solaris2.[89], sparc-sun-solaris2.8, sparc-sun-solaris2.10 and > the remaining tool combinati

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

Hallo! (Sorry for being late with this -- I'm listed as a GNU/Hurd OS Port Maintainer, but I have not been CCed in the original patch email, and I'm only able to read gcc-patches/the Git log at irregular times.) On Fri, 03 Jun 2011 16:35:21 +0200, Rainer Orth wrote: > gcc: > [...] >

[patch] Fix PR testsuite/49443

Hi, The loops in gcc.dg/vect/vect-peel-3.c and vect-peel-4.c have memory accesses with different misalignment values that cannot all be aligned by peeling. Therefore, these tests are not supposed to get vectorized on vect_no_align targets. This patch xfails the vectorization for such cases. Teste

Re: Simplify Solaris configuration

Rainer Orth writes: > Bootstrapped without regressions on i386-pc-solaris2.11 (Sun as/ld, GNU > as/Sun ld, GNU as, ld), i386-pc-solaris2.10 (Sun as/ld), and > sparc-sun-solaris2.11 (Sun as/ld) so far. Bootstraps on > i386-pc-solaris2.[89], sparc-sun-solaris2.8, sparc-sun-solaris2.10 and > the re

Re: Mark variables addressable if they are copied using libcall in RTL expander

On Tue, Jun 21, 2011 at 3:38 AM, Easwaran Raman wrote: > This fixes bugs introduced by r175063. OK for trunk if there are no > test regressions? I fear this isn't enough considering pass-by-value aggregates that are callee copied. And I guess there are other cases. Eric, what do you suggest her

Re: SRA generates uninitialized var use

On Tue, Jun 21, 2011 at 1:28 AM, Xinliang David Li wrote: > Good point -- but why does SRA have to be so complicated? If it just > do structure expansion and let subsequent phases to clean it up, would > it be simpler? Anyway this is off the topic. Well, it's certainly non-optimal to insert new m

Re: Backport AVX256 load/store split patches to gcc 4.6 for performance boost on latest AMD/Intel hardware.

On Tue, Jun 21, 2011 at 1:02 AM, Lu, Hongjiu wrote: >> >> The patch that disables default setting of unaligned load splitting >> for bdver1 has been committed >> to trunk as revision 175230. >> >> Here is the patch: http://gcc.gnu.org/ml/gcc-patches/2011- >> 06/msg01518.html. >> >> H. J., is there

Re: Patch: speed up compiler a little bit by optimizing lookup_attribute() and is_attribute_p()

On Tue, Jun 21, 2011 at 12:37 AM, Nicola Pero wrote: > This patch speeds up the C/C++/ObjC/ObjC++ compiler a little bit by optimizing > lookup_attribute() and is_attribute_p().  The main change is that these > functions > are now inline. I don't think this is a good idea. And I doubt that inlin

Re: [ARM] TLS Descriptor support

This patches addresses your comments. I've fixed: * config and option items Joseph pointed out in http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00719.html * md items Ramana pointed out in http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02109.html * option naming and assembly issues Richard pointed

Re: [Patch, Fortran, OOP] PR 49112: [4.6/4.7 Regression] Missing type-bound procedure, "duplicate save" warnings and internal compiler error

On Tue, Jun 21, 2011 at 12:29:01AM +0200, Janus Weil wrote: > However, I would also like to apply it to the 4.6 branch (which was > frozen a few hours ago). Is there any chance to get approval by the > RM's for this? Yeah, it looks small and safe enough for 4.6.1 to me. > 2011-06-21 Janus Weil

Re: [RFC] Fix unwind info for sparc -mflat

> I tried to figure out why things had been done in this > slightly convoluted manner and failed. It seems to me that > this is easily represented with the individual instructions. I wanted to avoid the back-and-forth game on the CFA offset and emit the same CFIs as in the normal case. Your sol

Re: [Patch, AVR]: Fix PR33049 (implement extzv)

2011/6/20 Georg-Johann Lay : > This is an optimization patch that implements extzv for 1-bit extracts. > +(define_insn_and_split "*extzv" > + [(set (match_operand:QI 0 "register_operand" > "=*d,*d,*d,r") > +(zero_extract:QI (match_operand:QI 1 "register_operand"