Re: [google] fix kernel fdo booting issue (issue4627057)

Okay for google/main. Sharad On Wed, Jun 22, 2011 at 11:22 PM, Rong Xu wrote: > > This change removes the define of TARGET_VTABLE_USES_DESCRIPTORS in > kernel fdo which causes kernel panic in indirect-call-profiling. > > Tested with 2.6.34 kernel. This change only affects kernel code. > > This i

Re: [PATCH 0/4] Docs: extend.texi

On Thu, Apr 28, 2011 at 01:20, Michael Witten wrote: > See the following emails for a few inlined patches > to /trunk/gcc/doc/extend.texi (revision 172911): > > [1] Docs: extend.texi: Add missing semicolon for consistency > [2] Docs: extend.texi: Remove trailing blanks from lines > [3] Docs: e

[google] fix kernel fdo booting issue (issue4627057)

This change removes the define of TARGET_VTABLE_USES_DESCRIPTORS in kernel fdo which causes kernel panic in indirect-call-profiling. Tested with 2.6.34 kernel. This change only affects kernel code. This is for google_main only. -Rong 2011-06-22 Rong Xu * gcc/libgcov.c: (TARGET_VTA

Re: [PATCH] Improve dump files for SRA early candidate check

> + if (!host_integerp (DECL_FIELD_OFFSET (fld), 1)) > + { > + *msg = "structure field offset not host integer"; /* ??? */ > + return true; > + } Offsets can be variable, like sizes, in Ada for example. >if (TYPE_VOLATILE (et)) > - r

Re: Add __builtin_clrsb, similar to clz/ctz

On Mon, Jun 20, 2011 at 12:38 PM, 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 @var{x}, star

[PATCH] Improve dump files for SRA early candidate check

From: Andi Kleen I wanted to figure out why some structures of mine don't get SRAed. Unfortunately the dump files were not very helpful because the variables got rejected early without any comments. This patch reports the actual reasons in the dump file. Passes test suite on x86-64 linux. Ok to

fix powerpc bootstrap failure

I'm applying this with David's blessing to fix the powerpc bootstrap failure that's been around for two weeks now. This is Jan's suggested fix, tweaked to avoid an overly long line. PR bootstrap/49383 * config/rs6000/rs6000.c (call_ABI_of_interest): Adjust cgraph invocatio

Re: [pph] Fix binding_level's names_size streaming (issue4634071)

On Wed, Jun 22, 2011 at 7:05 PM, Gabriel Charette wrote: > And it looks like this wasn't sent to anyone directly... > Adding back dnovillo and crowl (Diego I don't think Jason was ever > added to the original message...?) should not this go to mainline too? -- Gaby

Re: [pph] Fix binding_level's names_size streaming (issue4634071)

And it looks like this wasn't sent to anyone directly... Adding back dnovillo and crowl (Diego I don't think Jason was ever added to the original message...?) Gab On Wed, Jun 22, 2011 at 5:02 PM, Gabriel Charette wrote: > > See previous message. This patch only adds the fix to the dg-bogus comme

[pph] Fix binding_level's names_size streaming (issue4634071)

See previous message. This patch only adds the fix to the dg-bogus comment for the failing pph test. 2011-06-22 Gabriel Charette * gcc/cp/name-lookup.h (cp_binding_level): Removed unused member names_size. Update all users. diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-look

[pph] Fix binding_level's names_size streaming (issue4634071)

Here is the patch removing names_size. We found out it was write-only and that we could remove it. I tested it with a full bootstrap build as well as a full regression test (make check-g++). (actually one of the pph test fails, but that's because of a line number issue in where we expect the I

PR tree-optimize/49373 (IPA-PTA regression)

Hi, this patch moves ipa-pta into new ipa pass queue of simple IPA passes executed after regular IPA passes. The reason is that IPA-PTA is really implemented as simple IPA pass (i.e. it looks into function bodies at its propagate stage and does not support WHOPR mode) and I planned having place for

[pph] Fixed extra space typos in pph-streamer-out.c (issue4663041)

I've had these two small changes around for a while after making a search and replace for extra spaces in my own added code last week. Tested with bootstrap and pph regression testing, you never know ;) 2011-06-22 Gabriel Charette * gcc/cp/pph-streamer-out.c (pph_out_lang_specific):

Re: Rename attribs.c to attributes.c

On Wed, 22 Jun 2011, Andrew MacLeod wrote: > > Hmm, attribs.c to me is a perfect abbreviation to attributes.c, so it isn't > > unclear (to me) ... there are more confusing file names, like tree-dfa.c > > or tree-flow*.[ch]. > > > I also can't imagine what else attrib.c would be other than attribu

Re: [v3] Avoid -Wall warnings in the testsuite

On 22 June 2011 23:38, Jonathan Wakely wrote: > On 22 June 2011 22:48, Paolo Carlini wrote: >> ... all, besides that corresponding to c++/49508. >> >> Committed to mainline. >> >> Thanks, >> Paolo. >> >> // >> > > Oops, this bit is my bad, I'll fix it: > > Index: testsuite/20_util

Re: [v3] Avoid -Wall warnings in the testsuite

On 22 June 2011 22:48, Paolo Carlini wrote: > ... all, besides that corresponding to c++/49508. > > Committed to mainline. > > Thanks, > Paolo. > > // > Oops, this bit is my bad, I'll fix it: Index: testsuite/20_util/bind/socket.cc

Re: [pph] Stream scope_chain->bindings instead of global namespace (issue4661045)

So it looks like my mail using the upload script didn't make it out... let me retype it... On 2011/06/22 20:51:58, Diego Novillo wrote: http://codereview.appspot.com/4661045/diff/1/gcc/cp/pph-streamer-in.c File gcc/cp/pph-streamer-in.c (right): http://codereview.appspot.com/4661045/diff/1/gcc

[pph] Stream scope_chain->bindings instead of global namespace (issue4661045)

gcc/cp/pph-streamer-in.c:1003: namespace. 1001 /* FIXME pph: this carried over from pph_add_names_to_namespace, 1002 »it only makes sense to use this when merging names in an existing 1003 »namespace. pph_add_names_to_namespace does not exist anymore. I don't understan

Re: [v3] Avoid -Wall warnings in the testsuite

On 06/23/2011 12:04 AM, Andrew Pinski wrote: No I think that warning is correct "for (i;" the statement i; has no effect. Thanks, now I see, let's remove that i. Paolo.

Re: [v3] Avoid -Wall warnings in the testsuite

On Wed, Jun 22, 2011 at 3:02 PM, Paolo Carlini wrote: > ... actually, there are also bogus "statement has no effect" warnings for > line 1321 of ext/pb_ds/detail/pat_trie_/pat_trie_base.hpp which also seem > bogus: > >    PB_DS_CLASS_T_DEC >    typename PB_DS_CLASS_C_DEC::size_type >    PB_DS_CLAS

Re: [v3] Avoid -Wall warnings in the testsuite

... actually, there are also bogus "statement has no effect" warnings for line 1321 of ext/pb_ds/detail/pat_trie_/pat_trie_base.hpp which also seem bogus: PB_DS_CLASS_T_DEC typename PB_DS_CLASS_C_DEC::size_type PB_DS_CLASS_C_DEC:: get_begin_pos() const { size_type i =

[cxx-mem-model] sync_mem_exchange tests

And I propose this for the basic functionality tests. (I'm not using the one Aldy had in the original patch anymore) 'sync-mem.h' provides the bits required to test the existence and basic functionality of a sync_mem_exchange with all the valid memory models. All it is missing is a declaratio

[v3] Avoid -Wall warnings in the testsuite

... all, besides that corresponding to c++/49508. Committed to mainline. Thanks, Paolo. // 2011-06-22 Paolo Carlini * testsuite/20_util/reference_wrapper/invoke.cc: Avoid -Wall warnings. * testsuite/20_util/reference_wrapper/typedefs-3.cc: Likewise. *

Re: Cgraph alias reorg 15/14 (New infrastructure for same body aliases)

On Sun, 19 Jun 2011, Jan Hubicka wrote: > > > On Sat, 11 Jun 2011, Jan Hubicka wrote: > > > > > > > Hi, > > > > this patch complettes the same body alias rework by removing the old > > > > same body > > > > alias code and adding new representation. Same body aliases are now > > > > separate > >

Re: Rename attribs.c to attributes.c

On Wed, 22 Jun 2011 16:41:36 -0400 Diego Novillo wrote: > > You keep overgeneralizing and I think it is misleading. > > Existing reviewers will object to certain renames and/or cleanups when > they do not see a compelling value proposition. If you think that > your change brings value, but the

Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition)

> Date: Wed, 22 Jun 2011 20:16:48 +0200 > From: Hans-Peter Nilsson > > PR47836 > PR23656 > PR47733 > PR49247 > * configure.ac (target_libraries): Remove target-libiberty. ... JFTR, that's not proper PR annotation. I changed it as obvious to the following, which en

Re: [pph] Stream scope_chain->bindings instead of global namespace (issue4661045)

http://codereview.appspot.com/4661045/diff/1/gcc/cp/pph-streamer-in.c File gcc/cp/pph-streamer-in.c (right): http://codereview.appspot.com/4661045/diff/1/gcc/cp/pph-streamer-in.c#newcode1003 gcc/cp/pph-streamer-in.c:1003: namespace. 1001 /* FIXME pph: this carried over from pph_add_names_

Re: Rename attribs.c to attributes.c

On Wed, Jun 22, 2011 at 15:03, Basile Starynkevitch wrote: > On Wed, 22 Jun 2011 20:36:21 +0200 (CEST) > "Nicola Pero" wrote: > >> > Huh, I see no reason for this rename.  It'll just make patches across >> > releases harder. >> >> Sure.  But any change will make "patches across releases harder" .

[lra] a patch to speed up LRA

The following patch speeds up LRA mostly for architectures with moderate or large register files. The patch was successfully bootstrapped on x86-64, ia64, and ppc64. 2011-06-22 Vladimir Makarov * lra-assign.c (live_range_hard_reg_pseudos): Make it a sparseset. (live_range_har

Re: [PATCH][RFC][2/2] Bitfield lowering

On Thu, 16 Jun 2011, Richard Guenther wrote: > This implements lowering a subset of COMPONENT_REFs with DECL_BIT_FIELD > FIELD_DECLs and BIT_FIELD_REFs - thus bitfield operations in general. > It lowers those to memory loads/stores that the (non-strict-align) target > is able to carry out, adjusti

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

On 06/21/2011 03:27 PM, Andrew MacLeod wrote: > * doc/extend.texi (__sync_mem_exchange): Document. > * cppbuiltin.c (define__GNUC__): Define __SYNC_MEM*. > * c-family/c-common.c (BUILT_IN_SYNC_MEM_EXCHANGE_N): Add case. > * optabs.c (expand_sync_mem_exchange): New. > *

[PATCH] [annotalysis] Support IPA-SRA cloned functions (issue 4591066)

Hi, This patch is merely a port of an earlier patch, made by Le-Chun Wu, from google/main to annotalysis.  It extends Annotalysis to support cloned functions/methods (especially created by IPA-SRA). Bootstrapped and passed GCC regression testsuite on x86_64-unknown-linux-gnu. Okay for branches/a

Re: [PATCH] Change omp for static non-chunk computation (PR libgomp/49490)

On 06/22/2011 11:13 AM, Jakub Jelinek wrote: > Richard, do you agree with this? > > Bootstrapped/regtested on x86_64-linux and i686-linux. > > 2011-06-22 Jakub Jelinek > > PR libgomp/49490 > * omp-low.c (expand_omp_for_static_nochunk): Only > use n ceil/ nthreads size for th

Re: RFC: __gnu_cxx::__alloc_traits extension

On 11 June 2011 16:41, Jonathan Wakely wrote: > > 2011-06-11  Jonathan Wakely   > >        * include/Makefile.am: Add alloc_traits.h headers. >        * include/Makefile.in: Regenerate. >        * include/std/memory: Include uses_allocator.h explicitly. >        * include/bits/allocator.h (allocato

[pph] Stream scope_chain->bindings instead of global namespace (issue4661045)

We were streaming out the whole global namespace tree and only using its bindings on the way in. These bindings (defined by NAMESPACE_LEVEL (global_namespace)) are the same as scope_chain->bindings. Stream those bindings only instead. This also allows us to append the global_namespace itself to

Re: Rename attribs.c to attributes.c

On Wed, 22 Jun 2011 20:36:21 +0200 (CEST) "Nicola Pero" wrote: > > Huh, I see no reason for this rename. It'll just make patches across > > releases harder. > > Sure. But any change will make "patches across releases harder" ... does > it mean we can't make any changes - not even in phase 1 ?

Re: Rename attribs.c to attributes.c

On Wed, 22 Jun 2011 15:09:33 -0400 Andrew MacLeod wrote: > > > Hmm, attribs.c to me is a perfect abbreviation to attributes.c, so it isn't > > unclear (to me) ... there are more confusing file names, like tree-dfa.c > > or tree-flow*.[ch]. > > > I also can't imagine what else attrib.c would be o

PATCH: PR rtl-optimization/49504: Invalid optimization for Pmode != ptr_mode

Hi, I just don't see how nonzero_bits1 can assume if pointers extend unsigned and this is an addition or subtraction to a pointer in Pmode, all the bits bove ptr_mode are known to be zero. We never run into it before x32 since x32 is the first such target. This patch deletes it. OK to install t

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

On Wed, Jun 22, 2011 at 7:13 AM, Eric Botcazou wrote: >> I fear this isn't enough considering pass-by-value aggregates that >> are callee copied. > > It's indeed not sufficient for arguments passed by reference but > callee-copied. > > This is PR target/49454.  For gcc.c-torture/execute/2717-

Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition)

> Ok for trunk? Ok with me. I'll let the branch maintainers decide if they want it for their branches.

Re: Rename attribs.c to attributes.c

On Wed, 22 Jun 2011, Nicola Pero wrote: > > Huh, I see no reason for this rename. It'll just make patches across > > releases harder. > > Sure. But any change will make "patches across releases harder" ... does > it mean we can't make any changes - not even in phase 1 ? :-( I think moving file

Re: Rename attribs.c to attributes.c

Hmm, attribs.c to me is a perfect abbreviation to attributes.c, so it isn't unclear (to me) ... there are more confusing file names, like tree-dfa.c or tree-flow*.[ch]. I also can't imagine what else attrib.c would be other than attributes...

Move params code and hook to libcommon-target

This patch continues preparing for the driver to use the option-handling hooks from cc1 by moving the definitions of --param arguments and associated target-specific defaults to common code. The params themselves go in params.c along with the initialization code formerly in toplev.c; the hook TARG

Re: [pph] Initialize cache_ix in all paths in pph_start_record (issue4642045)

On 2011/06/18 01:29:31, Gabriel Charette wrote: 2011-06-17 Gabriel Charette * gcc/cp/pph-streamer-in.c (pph_start_record): Initialize cache_ix in all paths. OK. Applied to branch. Diego. http://codereview.appspot.com/4642045/

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

On 2011/06/21 18:56:24, Gabriel Charette wrote: 2011-06-21 Gabriel Charette * gcc/cp/pph-streamer-in.c (pph_in_tree_vec): Make static. (pph_add_names_to_namespace): Moved from pph.c. (wrap_macro_def): Moved from pph.c. (report_valid

Re: [pph] Rename two pph_start_record functions adding in/out. (issue4629049)

On 2011/06/17 23:18:21, Gabriel Charette wrote: 2011-06-17 Gabriel Charette * gcc/cp/pph-streamer-in.c (pph_in_start_record): Rename from pph_start_record. Update all users. * gcc/cp/pph-streamer-out.c (pph_out_start_record): Rename

Re: Rename attribs.c to attributes.c

On Wed, Jun 22, 2011 at 8:36 PM, Nicola Pero wrote: >> Huh, I see no reason for this rename.  It'll just make patches across >> releases harder. > > Sure.  But any change will make "patches across releases harder" ... does > it mean we can't make any changes - not even in phase 1 ? :-( No, not in

Re: Rename attribs.c to attributes.c

> Huh, I see no reason for this rename. It'll just make patches across > releases harder. Sure. But any change will make "patches across releases harder" ... does it mean we can't make any changes - not even in phase 1 ? :-( The reason I'd like to change the name is that "attribs.c" is meaningl

Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition)

> Date: Mon, 20 Jun 2011 16:58:41 + (UTC) > From: "Joseph S. Myers" > On Mon, 20 Jun 2011, Hans-Peter Nilsson wrote: > > > It seems none in approval capacity have any objection to > > (figuratively) s/target-libiberty//g in toplevel/configure.ac on > > all branches. Is an --enable-target-li

Re: [pph] Fix binding_level's names_size streaming (issue4634071)

On Mon, Jun 20, 2011 at 21:12, Gabriel Charette wrote: > It appears names_size is not even used anywhere in the code > (or at least I couldn't find any use of it with `grep "names_size" -R gcc/`. > Should we just remove it? Yes, we should remove it. Jason, the field cp_binding_level.names_size

[PATCH] Change omp for static non-chunk computation (PR libgomp/49490)

Hi! As has been reported, we don't divide the work for schedule(static) loops very well. E.g. for 33 iterations with 8 threads, we give 5 iterations to the first 6 threads, 3 iterations to the 7th thread and 0 iterations to the last thread in the team. The reason for that is the q = n / n

Re: Rename attribs.c to attributes.c

On Wed, Jun 22, 2011 at 7:18 PM, Nicola Pero wrote: > This patch renames attribs.c to attributes.c. > > I can only imagine the short "attribs.c" name was picked many years ago > due to filename restrictions on certain systems ?  Nowadays, it seems > that we already have plenty of long filenames in

[PATCH] Fix PR49493

This fixes PR49493. Bootstrapped and tested on x86_64-unknown-linx-gnu, committed. Richard. 2011-06-22 Richard Guenther PR tree-optimization/49493 * tree-ssa-structalias.c (get_constraint_for_ssa_var): Refer to the alias target of variables. (associate_varinf

Re: [PATCH] Fix a -fcompare-debug bug in the vectorizer (PR debug/49496)

On Wed, Jun 22, 2011 at 7:02 PM, Jakub Jelinek wrote: > Hi! > > This bug has been introduced recently, we shouldn't take debug uses into > account when deciding whether to optimize. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Ok. Thanks, Richard. > 2011-06-22  Jakub

[boehm-gc] Use __rld_obj_head for IRIX GC_register_dynamic_libraries (PR libgcj/49451)

As reported in PR libgcj/49451, the FileHandleGcTest test fails on IRIX since boehm-gc tries to open /proc/ when the process is already out of file descriptors. Looking around, I've found a way for boehm-gc to determine the list of shared libraries without using /proc, just as Solaris and Tru64 UN

Rename attribs.c to attributes.c

This patch renames attribs.c to attributes.c. I can only imagine the short "attribs.c" name was picked many years ago due to filename restrictions on certain systems ? Nowadays, it seems that we already have plenty of long filenames inside GCC, so there is no reason to use cryptic, newbie-unfrien

Re: [ARM] TLS Descriptor support

On 06/21/11 18:24, Ramana Radhakrishnan wrote: revalidated with defaults to both gnu and gnu2 style. ok? This is OK . sigh, in backporting the relevant bits, I noticed a problem with the OPTION_DEFAULT_SPECS string, fixed thusly, committed as obvious. And then I noticed I'd failed to commi

[PATCH] Fix a -fcompare-debug bug in the vectorizer (PR debug/49496)

Hi! This bug has been introduced recently, we shouldn't take debug uses into account when deciding whether to optimize. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2011-06-22 Jakub Jelinek PR debug/49496 * tree-vect-patterns.c (vect_recog_widen_mult_p

Re: [Patch, AVR]: Fix PR46779

Hans-Peter Nilsson schrieb: > 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" * "

[Patch, AVR]: FIX PR43746 (merge progmem strings)

This patch will put progmem strings into a mergeable strings section. progmem_section is globally renamed to progmem_sw_table_section as it's only used for switch_case jumptables. The code that attached the explicit section name ".progmem" in avr_insert_attributes is removed. Instead, avr_init_s

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

Hi, On Tue, Jun 21, 2011 at 05:12:40PM +0200, 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. > > Richard. > > 2008-04-11 Richard Guenther > > * builtin-attrs.def (

Re: [PATCH, alpha]: Skip some TLS -pie tests

On Wed, Jun 22, 2011 at 5:56 PM, Richard Henderson wrote: Some -pie TLS tests are unsupported due to "TLS local exec code cannot be linked into shared objects". >>> >>> Is there something about the Alpha ABI that makes it impossible to support >>> for PIEs (which are different from shar

Re: [PATCH, alpha]: Skip some TLS -pie tests

On 06/22/2011 08:32 AM, Uros Bizjak wrote: > On Wed, Jun 22, 2011 at 3:04 PM, Joseph S. Myers > wrote: > >>> Some -pie TLS tests are unsupported due to "TLS local exec code cannot >>> be linked into shared objects". >> >> Is there something about the Alpha ABI that makes it impossible to support

C++ PATCH for c++/49260 (lambda-eh2.C failure on several targets)

This failure was happening on all targets that don't use either CFI assembler directives or asynchronous unwind tables: we were mistakenly deciding that the _FUN thunk for returning from the lambda function pointer conversion operator couldn't throw because build_call_a wasn't setting cp_functi

Re: [Patch] PR c++/26256

On 06/15/2011 01:58 PM, Fabien Chêne wrote: Otherwise, perhaps that it would be better if the second declaration of E1 does not rely on supplement_binding_1. What do you think ? I agree. We should be using xref_tag for this like we do with classes, so we don't try to push the same tag more th

Re: [PATCH, alpha]: Skip some TLS -pie tests

On Wed, Jun 22, 2011 at 3:04 PM, Joseph S. Myers wrote: >> Some -pie TLS tests are unsupported due to "TLS local exec code cannot >> be linked into shared objects". > > Is there something about the Alpha ABI that makes it impossible to support > for PIEs (which are different from shared libraries

Re: PATCH: PR target/49497: Incorrect lea peephole

On Wed, Jun 22, 2011 at 4:17 PM, H.J. Lu wrote: > We should check !TARGET_PARTIAL_REG_STALL for imul to lea peepholes. > Also there is no partial register stall for SImode.  I also added > const359_operand as suggestd by Uros. > > OK for trunk? > > Thanks. > > > H.J. > --- > 2011-06-22  H.J. Lu  

Re: RFA PR middle-end/48770

On 06/14/2011 05:32 PM, Jeff Law wrote: > > This version incorporates suggestions from Bernd. Basically we have > reload1.c set reload_completed internally rather than deferring it into > ira.c. That allows the call to reload() to return whether or not a DCE > pass is desirable at the end of rel

PATCH: PR target/49497: Incorrect lea peephole

Hi, We should check !TARGET_PARTIAL_REG_STALL for imul to lea peepholes. Also there is no partial register stall for SImode. I also added const359_operand as suggestd by Uros. OK for trunk? Thanks. H.J. --- 2011-06-22 H.J. Lu PR target/49497 * config/i386/i386.md (*lea_gen

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

> I fear this isn't enough considering pass-by-value aggregates that > are callee copied. It's indeed not sufficient for arguments passed by reference but callee-copied. This is PR target/49454. For gcc.c-torture/execute/2717-1.c: typedef struct trio { int a, b, c; } trio; int foo (trio t,

[PATCH] Fix PR49365

This fixes the prefetching regression caused by rev. 166552 by adjusting the default min-insn-to-prefetch-ratio. I benchmarked SPEC2006 with this change on AMD hardware (where prefetching is on by default) and apart from recovering the 436.cactusADM regression there is no other change in performa

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

On Tue, 21 Jun 2011, Richard Guenther wrote: > 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 th

Re: Improve jump threading #5 of N

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/21/11 21:28, Hans-Peter Nilsson wrote: > 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

Re: SRA generates uninitialized var use

Hi, On Tue, Jun 21, 2011 at 06:08:27PM +0200, Richard Guenther wrote: > 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 doe

Re: [PATCH] parallelize gcc, gfortran and libstdc++ testing some more

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/11 15:04, Jakub Jelinek wrote: > On Mon, Jun 20, 2011 at 03:54:59PM +0200, Jakub Jelinek wrote: >> On Mon, Jun 20, 2011 at 09:28:56AM -0400, Jason Merrill wrote: >>> On 06/17/2011 08:20 PM, Mike Stump wrote: On Jun 17, 2011, at 10:47 AM,

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

On Wed, Jun 22, 2011 at 3:14 PM, Jakub Jelinek wrote: > On Wed, Jun 22, 2011 at 03:08:21PM +0200, Eric Botcazou wrote: >> > 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 here? >> >> I a

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

On Wed, Jun 22, 2011 at 03:08:21PM +0200, Eric Botcazou wrote: > > 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 here? > > I agree that there are probably other cases, but this seems to b

[patch tree-ssa-forwprop]: Improve binary and/or/xor folding

Hello, This patch improves via type-sinking folding of binary and, or, and xor operations. First we do sinking also for compatible types with same precision, as those don't need to be preserved for these operations. Additional try to fold patterns (TYPE) X bin-op (Y CMP Z) and (TYPE) X bin-op !Y,

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

> 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 here? I agree that there are probably other cases, but this seems to be the best way out for now. There is still similar code in the expander

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

On Wed, 22 Jun 2011, Michael Matz wrote: > Hi, > > On Tue, 21 Jun 2011, Richard Guenther wrote: > > > I failed to see where the scalarizer inserts the temporary vars it > > creates into the scope blocks (thus the gimplify.c hunk ...). Any help > > here is welcome. > > The scoping of the scal

Re: [PATCH, alpha]: Skip some TLS -pie tests

On Wed, 22 Jun 2011, Uros Bizjak wrote: > Hello! > > Some -pie TLS tests are unsupported due to "TLS local exec code cannot > be linked into shared objects". Is there something about the Alpha ABI that makes it impossible to support for PIEs (which are different from shared libraries)? The con

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

Hi, On Tue, 21 Jun 2011, Richard Guenther wrote: > I failed to see where the scalarizer inserts the temporary vars it > creates into the scope blocks (thus the gimplify.c hunk ...). Any help > here is welcome. The scoping of the scalarizer is a bit funny. gfc_start_scalarized_body sets up s

Re: [PATCH, libgcc]: Prototype __enable_execute_stack

On Wed, Jun 22, 2011 at 10:23 AM, Rainer Orth wrote: >> This patch avoids a bunch of: >> >> enable-execute-stack.c:5:1: warning: no previous prototype for >> ‘__enable_execute_stack’ [-Wmissing-prototypes] >> >> warnings during gcc bootstrap. > > I'd say this is obvious. Agreed. Committed to ma

[PATCH, alpha]: Skip some TLS -pie tests

Hello! Some -pie TLS tests are unsupported due to "TLS local exec code cannot be linked into shared objects". 2011-06-22 Uros Bizjak * gcc.dg/torture/tls/run-le.c: Skip for -pie on alpha*-*-linux*. * gcc.dg/torture/tls/tls-test.c: Ditto. * gcc.dg/torture/tls/thr-init-1

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

On Wed, Jun 22, 2011 at 2:17 AM, Nicola Pero wrote: > 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

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

On Tue, Jun 21, 2011 at 6:31 PM, Jakub Jelinek wrote: > 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 retur

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

On 22/06/11 00:25, Ramana Radhakrishnan wrote: >> >> 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.g

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

On 21/06/11 22:05, Janis Johnson wrote: > 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? > > > gcc-20110621-4 > > > 2011-06-21 Janis Johnson >

Re: [testsuite] ARM: adjust skips for Xscale test

On 21/06/11 22:03, Janis Johnson wrote: > 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? > > > gcc-20110621-2 > > > 2011-06-21 Janis Johnson >

Re: [PATCH, libgcc]: Prototype __enable_execute_stack

Hi Uros, > This patch avoids a bunch of: > > enable-execute-stack.c:5:1: warning: no previous prototype for > ‘__enable_execute_stack’ [-Wmissing-prototypes] > > warnings during gcc bootstrap. I'd say this is obvious. > 2011-06-22 Uros Bizjak > > * enable-execute-stack-empty.c (__enable

[PATCH, libgcc]: Prototype __enable_execute_stack

Hello! This patch avoids a bunch of: enable-execute-stack.c:5:1: warning: no previous prototype for ‘__enable_execute_stack’ [-Wmissing-prototypes] warnings during gcc bootstrap. 2011-06-22 Uros Bizjak * enable-execute-stack-empty.c (__enable_execute_stack): Add prototype. Bootstra