On Thu, Dec 13, 2012 at 1:30 AM, Jakub Jelinek wrote:
> On Wed, Dec 12, 2012 at 10:16:49PM +0100, Dodji Seketeli wrote:
>> Independently of this review, I think it's be interesting to hear
>> Kostya's voice on:
>>
>> Jakub Jelinek writes:
>>
>> > 2) In large-func-test-1.C, I had to stop matching
Il 13/12/2012 00:23, H.J. Lu ha scritto:
> On Wed, Dec 12, 2012 at 3:01 PM, H.J. Lu wrote:
>> On Wed, Dec 12, 2012 at 2:13 PM, Paolo Bonzini wrote:
>>> Il 12/12/2012 19:11, H.J. Lu ha scritto:
in RAW_CXX_TARGET_EXPORTS. There is no need to do anything.
>>
>> Nope, if yo
Try the following one. 1) -minline-all-stringops
-mstringop-strategy=rep_8byte -O2 vs 1) -mstringop_strategy=libcall
-O2.
David
#include
#include
#include
#ifndef LEN
#define LEN 16
#endif
void copy(char* s1, char* s2,int len) __attribute__((noinline));
void copy(char* s1, char* s2,int len)
On Thu, Dec 13, 2012 at 1:58 AM, Richard Henderson wrote:
> On 12/12/2012 11:50 AM, Jakub Jelinek wrote:
>> 2012-12-12 Jakub Jelinek
>>
>> PR sanitizer/55508
>> * builtin-attrs.def (ATTR_TMPURE_NOTHROW_LEAF_LIST,
>> ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST): New.
>> * asan
On Wed, Dec 12, 2012 at 11:50 PM, Jakub Jelinek wrote:
> Hi!
>
> Various TM tests ICE when built with -fgnu-tm -fsanitizer=address.
> The problem is that asan.c pass adds calls to builtins that weren't there
> before and TM is upset about it. The __asan_report* are all like
> abort, in correctly
On Wed, Dec 12, 2012 at 10:09:14PM -0800, Xinliang David Li wrote:
> On Wed, Dec 12, 2012 at 5:19 PM, Jan Hubicka wrote:
> >> > libcall is not faster up to 8KB to rep sequence that is better for
> >> > regalloc/code
> >> > cache than fully blowin function call.
> >>
> >> Be careful with this. My
On Wed, Dec 12, 2012 at 5:19 PM, Jan Hubicka wrote:
>> > libcall is not faster up to 8KB to rep sequence that is better for
>> > regalloc/code
>> > cache than fully blowin function call.
>>
>> Be careful with this. My recollection is that REP sequence is good for
>> any size -- for smaller size,
Hello Everyone,
This patch is for Cilk Plus branch affecting mainly the C compiler. It
checks to see if the gotos and increment expressions inside cilk_for are valid
and report errors otherwise.
Thanks,
Balaji V. Iyer.
Index: gcc/c-family/c-cilk.c
===
> > libcall is not faster up to 8KB to rep sequence that is better for
> > regalloc/code
> > cache than fully blowin function call.
>
> Be careful with this. My recollection is that REP sequence is good for
> any size -- for smaller size, the REP initial set up cost is too high
> (10s of cycles),
On Wed, Dec 12, 2012 at 4:16 PM, Xinliang David Li wrote:
> On Wed, Dec 12, 2012 at 10:30 AM, Jan Hubicka wrote:
>> Concerning 1push per cycle, I think it is same as K7 hardware did, so move
>> prologue should be a win.
>>> > Index: config/i386/i386.c
>>> > ===
On Wed, Dec 12, 2012 at 10:30 AM, Jan Hubicka wrote:
> Concerning 1push per cycle, I think it is same as K7 hardware did, so move
> prologue should be a win.
>> > Index: config/i386/i386.c
>> > ===
>> > --- config/i386/i386.c (revisi
On Tue, Dec 11, 2012 at 02:44:41PM -0800, Lawrence Crowl wrote:
> +/* Hash a tree in a uid_decl_map. */
> +
> +inline hashval_t
> +uid_decl_hasher::hash (const value_type *item)
> +{
> + return item->decl_minimal.uid;
Ugh, why aren't you using DECL_UID here? The fact that DECL_UID is right
now
Fixup for a typo, on trunk and 4.7
-benjamin2012-12-12 Benjamin Kosnik
* doc/xml/manual/documentation_hacking.xml: Fix validation issue.
diff --git a/libstdc++-v3/doc/xml/manual/documentation_hacking.xml b/libstdc++-v3/doc/xml/manual/documentation_hacking.xml
index 91d16dd..05c05a6 100644
The Go spec was changed slightly: calling delete on a nil map is now a
no-op, rather than causing a runtime panic. This patch implements that
in gccgo. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
Index: libgo/runtime/go-map-delete.c
===
On Wed, Dec 12, 2012 at 3:01 PM, H.J. Lu wrote:
> On Wed, Dec 12, 2012 at 2:13 PM, Paolo Bonzini wrote:
>> Il 12/12/2012 19:11, H.J. Lu ha scritto:
> >>
> >> in RAW_CXX_TARGET_EXPORTS. There is no need to do anything.
>
> Nope, if you remove this you get the wrong definition of
On Wed, Dec 12, 2012 at 2:58 PM, Jakub Jelinek wrote:
> 2012-12-12 Jakub Jelinek
>
> PR debug/55665
> * tree-inline.c (remap_decls): Change nonlocalized_list
> to pointer to pointer to vector from pointer to vector.
> (remap_block): Pass address of BLOCK_NONLOCA
I've updated libgo to the current master Go library sources. As usual
this e-mail only includes patches to files that are substantially
specific to gccgo. The bulk of the patch is available from the
repository or from the master Go repository. Bootstrapped and ran Go
testsuite on x86_64-unknown-
On 11 December 2012 22:31, Jonathan Wakely wrote:
> PR libstdc++/55631
> * include/ext/alloc_traits.h: Include missing header.
> * include/ext/pointer.h: Likewise.
> * include/ext/string_conversions.h: Require C++11.
> * libsupc++/initializer_list: Reindent.
On Wed, Dec 12, 2012 at 2:13 PM, Paolo Bonzini wrote:
> Il 12/12/2012 19:11, H.J. Lu ha scritto:
>>
>> in RAW_CXX_TARGET_EXPORTS. There is no need to do anything.
>>> >
>>> > Nope, if you remove this you get the wrong definition of CC and CXX from
>>> > EXTRA_TARGET_FLAGS. Instead, you
On 12/12/12, Diego Novillo wrote:
> On Dec 11, 2012 Lawrence Crowl wrote:
> > Convert tree-sra.c'candidates from htab_t to hash_table.
> >
> > Fold uid_decl_map_hash and uid_decl_map_eq into new struct
> > uid_decl_hasher. This change moves the definitions from tree-ssa.c
> > into tree-sra.c and
On Wed, 2012-12-12 at 22:21 +, Maciej W. Rozycki wrote:
> Given that, how about we coordinate these submissions -- I'll dig out the
> most recent version of the madd change and push it through testing before
> I post it and you do the reciprocals?
>
> Maciej
That sounds good to me.
Ste
Steve,
Thanks for raising my attention, I've got a proposal below.
> The MIPS32 architecture supports madd, msub, nmadd, and nmsub instructions
> as well as rsqrt and recip instructions even when it doesn't have a 64 bit
> floating point unit. This was not clear in the original MIPS32 architect
Il 12/12/2012 19:11, H.J. Lu ha scritto:
>>> >>
>>> >> in RAW_CXX_TARGET_EXPORTS. There is no need to do anything.
>> >
>> > Nope, if you remove this you get the wrong definition of CC and CXX from
>> > EXTRA_TARGET_FLAGS. Instead, you need to add RAW_CXX_FOR_TARGET to
>> > AM_MAKEFLAGS and EXTRA
The MIPS32 architecture supports madd, msub, nmadd, and nmsub instructions
as well as rsqrt and recip instructions even when it doesn't have a 64 bit
floating point unit. This was not clear in the original MIPS32 architecture
document (MD00086) but was clarified in 2011 (version 3.0.2, March 21, 2
On 12/12/2012 11:50 AM, Jakub Jelinek wrote:
> 2012-12-12 Jakub Jelinek
>
> PR sanitizer/55508
> * builtin-attrs.def (ATTR_TMPURE_NOTHROW_LEAF_LIST,
> ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST): New.
> * asan.c (ATTR_TMPURE_NOTHROW_LEAF_LIST,
> ATTR_TMPURE_NORETURN_NO
On Wed, Dec 12, 2012 at 08:50:33PM +0100, Jakub Jelinek wrote:
> Hi!
>
> Various TM tests ICE when built with -fgnu-tm -fsanitizer=address.
> The problem is that asan.c pass adds calls to builtins that weren't there
> before and TM is upset about it. The __asan_report* are all like
> abort, in co
The small memory model will not do since I want to put data at other
distinct addresses above 4G. I also want to place the heap at yet another
address interval. This way it becomes easy to separate out code, data and
heap references, and making sure that pointers are valid. The primary reason
f
Hello,
Independently of this review, I think it's be interesting to hear
Kostya's voice on:
Jakub Jelinek writes:
> 2) In large-func-test-1.C, I had to stop matching the backtrace after
> _Znw[jm], because libasan is using the fast but inaccurate backtrace,
> and while the tests can be easily t
On Wed, Dec 12, 2012 at 10:16:49PM +0100, Dodji Seketeli wrote:
> Independently of this review, I think it's be interesting to hear
> Kostya's voice on:
>
> Jakub Jelinek writes:
>
> > 2) In large-func-test-1.C, I had to stop matching the backtrace after
> > _Znw[jm], because libasan is using th
Jakub Jelinek writes:
> PR sanitizer/55508
> * builtin-attrs.def (ATTR_TMPURE_NOTHROW_LEAF_LIST,
> ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST): New.
> * asan.c (ATTR_TMPURE_NOTHROW_LEAF_LIST,
> ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST): Define.
> * sanitizer.def: Mak
On Wed, Dec 12, 2012 at 12:56 PM, Leif Ekblad wrote:
> I'm working on OS-adaptations for an OS that would use x86-64 applications
> that are located above 4G, but not in the upper area. Binutils provide a
> function to be able to set the start of text to above 4G, but there are
> problems with GCC
I'm working on OS-adaptations for an OS that would use x86-64 applications
that are located above 4G, but not in the upper area. Binutils provide a
function to be able to set the start of text to above 4G, but there are
problems with GCC when using this memory model.
The first issue has to do
This is the next set of patches for native TLS support on AIX. This
mainly adds support for BSS symbols. This should use local common and
I created a tbss section name, but I cannot figure out how to convince
the AIX assembler to match the TOC symbols reference to the lcomm
symbol. Disassembly of
Hi!
Before http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193595
aka the big vec.h changes, nonlocalized_list parameter to remap_decls
used to be **, but the changes changed it to *. That is a problem,
because then there is no difference between the case where we don't
want to push anything to
Hi!
This is something I've changed recently on the C++ side, but C has similar
issue as the testcase shows. For "m" or other constraints that allow memory
and don't allow registers, we want to mark the operand addressable (thus
handle it quite lvalue-ish, except that we know it won't be written t
Hi!
Various TM tests ICE when built with -fgnu-tm -fsanitizer=address.
The problem is that asan.c pass adds calls to builtins that weren't there
before and TM is upset about it. The __asan_report* are all like
abort, in correctly written program they shouldn't have a user visible
effect, in bad p
Hi!
This is a follow-up fix for my earlier commit, in merge_exception_specifiers
can be NULL, noex == boolean_true_node comparison then was false, but
operand_equal_p crashes on it.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2012-12-12 Jakub Jelinek
Hi!
On the attached testcase prg_ctr_mask is non-zero, presumably set
while there still were some functions in the TU, but later on none of them
are being emitted. This leads to n_functions in coverage_obj_finish being
0, and the array thus containing 0x1 elements.
Fixed thusly, bootstra
Hi,
I added two testcases to this patch. So that we might detect
regressions about this issue later more easily.
2012-12-12 Kai Tietz
PR c/52991
* stor-layout.c (start_record_layout): Handle
packed-attribute for ms-structure-layout.
(update_alignment_for_field)
On 12/12/2012 10:32 AM, Uros Bizjak wrote:
> Please check the attached patch, it implements this limitation in a correct
> way:
> - keeps memory operands for -Os or cold parts of the executable
> - doesn't increase register pressure
> - handles all situations where memory operand can propagate int
Steve Ellcey writes:
> OK, you have convinced me. Here is what I am testing, OK to checkin
> once I have run it through the testsuite?
Yeah, looks good, thanks.
Richard
Andi Kleen writes:
>
>>> >/* X86_TUNE_FOUR_JUMP_LIMIT: Some CPU cores are not able to predict
>>> > more
>>> > than 4 branch instructions in the 16 byte window. */
>>> > - m_PPRO | m_P4_NOCONA | m_CORE2I7 | m_ATOM | m_AMD_MULTIPLE | m_GENERIC,
>>> > + m_PPRO | m_P4_NOCONA | m_ATOM |
> Jan Hubicka writes:
> >
> > libcall is not faster up to 8KB to rep sequence that is better for
> > regalloc/code
> > cache than fully blowin function call.
>
> I noticed btw that some of the generated string instructions are slower
> than just calling the C library.
>
> rep scasb etc. is rar
Jan Hubicka writes:
>
> libcall is not faster up to 8KB to rep sequence that is better for
> regalloc/code
> cache than fully blowin function call.
I noticed btw that some of the generated string instructions are slower
than just calling the C library.
rep scasb etc. is rarely a win over an op
On Wed, Dec 12, 2012 at 3:45 PM, Richard Biener
wrote:
>> I assume that this is not right way for fixing such simple performance
>> anomaly since we need to do redundant work - combine load to
>> conditional and then split it back in peephole2? Does it look
>> reasonable? Why we should produce no
Concerning 1push per cycle, I think it is same as K7 hardware did, so move
prologue should be a win.
> > Index: config/i386/i386.c
> > ===
> > --- config/i386/i386.c (revision 194452)
> > +++ config/i386/i386.c (working copy)
> > @@
On Wed, Dec 12, 2012 at 1:53 PM, Richard Biener wrote:
> + fputs ("digraph \"\" { overlap=false;\n", fp);
This is "start_graph_dump (fp);"
> + fputs ("}\n", fp);
And this is "end_graph_dump (fp);"
I think it'd be good to call those functions instead of the fputs
calls. Keeps things consist
On Wed, Dec 12, 2012 at 10:01 AM, Paolo Bonzini wrote:
> Il 12/12/2012 18:30, H.J. Lu ha scritto:
>> On Wed, Dec 12, 2012 at 6:46 AM, Paolo Bonzini wrote:
>>> Il 12/12/2012 15:41, H.J. Lu ha scritto:
MAKEOVERRIDES is used for multilib. I got
/bin/sh ../libtool --tag=CXX --mode=c
Richard Biener writes:
>
> Probably not suitable for trunk because I use popen/pclose/fileno
> which I don't know whether they are available on all host platforms.
Just add a ifdef HAVE_popen or somesuch around it?
-Andi
--
a...@linux.intel.com -- Speaking for myself only
Il 12/12/2012 18:30, H.J. Lu ha scritto:
> On Wed, Dec 12, 2012 at 6:46 AM, Paolo Bonzini wrote:
>> Il 12/12/2012 15:41, H.J. Lu ha scritto:
>>> MAKEOVERRIDES is used for multilib. I got
>>>
>>> /bin/sh ../libtool --tag=CXX --mode=compile -D_GNU_SOURCE -D_DEBUG
>>> -D__STDC_CONSTANT_MACROS -D_
On Wed, Dec 12, 2012 at 9:30 AM, H.J. Lu wrote:
> After further investigation, I found
>
> RAW_CXX_TARGET_EXPORTS = \
> $(BASE_TARGET_EXPORTS) \
> CXX_FOR_TARGET="$(RAW_CXX_FOR_TARGET)"; export CXX_FOR_TARGET; \
> CXX="$(RAW_CXX_FOR_TARGET) $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS
I think this patch qualifies as obvious so I will check it in later today if
I don't get any objections. These two tests use the -fPIC flag but do not
check for pic support. Tested on mips-mti-elf.
Steve Ellcey
sell...@mips.com
2012-12-12 Steve Ellcey
* gcc.dg/pr55150-2.c: Add pic
Hello,
This patch fixes a regression in the size of bitmap_head that resulted
from the removal of all the #ifdef GATHER_STATISTICS tests.
Instead of a pointer to a descriptor, this patch gives each bitmap an
integer that is the index of the bitmap_descriptor.
Bootstrapped&tested on powerpc64-unk
Honza, can you explain each change and point to the reference?
thanks,
David
On Wed, Dec 12, 2012 at 8:37 AM, Jan Hubicka wrote:
>> I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
>> SP adjustment instead of a sequence of pushes/pops. The preference to
>> the MOVs are good
On Wed, Dec 12, 2012 at 6:46 AM, Paolo Bonzini wrote:
> Il 12/12/2012 15:41, H.J. Lu ha scritto:
>> MAKEOVERRIDES is used for multilib. I got
>>
>> /bin/sh ../libtool --tag=CXX --mode=compile -D_GNU_SOURCE -D_DEBUG
>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
>> -DA
On Wed, Dec 12, 2012 at 8:37 AM, Jan Hubicka wrote:
>> I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
>> SP adjustment instead of a sequence of pushes/pops. The preference to
>> the MOVs are good for old CPU micro-architectures (before pentium-4,
>> K10), because it breaks t
On Wed, 2012-12-12 at 08:21 +, Richard Sandiford wrote:
> I'm pretty sure we'll need more eventually though. A quick inspection
> shows that we don't set mips_dbx_regno for DSP_ACC_REGS or ST_REGS.
> DSP_ACC_REGS in paticular seems likely to hit, although you need to
> test with an -mdsp opti
Dear all,
first, I like to ping two patches:
* MOVE_ALLOC: http://gcc.gnu.org/ml/fortran/2012-12/msg00058.html
* MODULE renaming: http://gcc.gnu.org/ml/fortran/2012-12/msg00022.html
Note: The proper PR number is 55197.
* * *
Secondly, the attached patch allows VALUE arguments to ELEMENTAL w
> I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
> SP adjustment instead of a sequence of pushes/pops. The preference to
> the MOVs are good for old CPU micro-architectures (before pentium-4,
> K10), because it breaks the data dependency. In modern
> micro-architecture, push
2012/12/12 Richard Biener :
> On Wed, Dec 12, 2012 at 4:11 PM, Richard Henderson wrote:
>> On 12/12/2012 02:57 AM, Richard Biener wrote:
>>> That looks wrong. Having both TYPE_PACKED and TYPE_ALIGN != BITS_PER_UNIT
>>> is inconsistent, so this part of the patch should not be necessary.
>>
>> No,
On Wed, Dec 12, 2012 at 01:41:49PM +0100, Steven Bosscher wrote:
> On Wed, Dec 12, 2012 at 1:17 PM, Steven Bosscher wrote:
> > I'll resubmit for GCC 4.9. Instead of a test case, I have a verifier
> > queued that asserts no BARRIERs appear in the insns stream when in
> > cfglayout mode. (This verifi
On Wed, Dec 12, 2012 at 4:11 PM, Richard Henderson wrote:
> On 12/12/2012 02:57 AM, Richard Biener wrote:
>> That looks wrong. Having both TYPE_PACKED and TYPE_ALIGN != BITS_PER_UNIT
>> is inconsistent, so this part of the patch should not be necessary.
>
> No, that is the only way to give a 4 by
On 12/07/2012 04:02 PM, Marc Glisse wrote:
> 2012-12-08 Marc Glisse
>
> PR target/54855
> gcc/
> * config/i386/sse.md (_vm3): Rewrite
> pattern.
> (sse2_loadlpd, sse2_loadhpd): Use vec_merge.
> * config/i386/i386-builtin-types.def: New function types.
> * config/i386/i38
On Wed, Dec 12, 2012 at 7:25 AM, Richard Biener wrote:
> On Wed, 12 Dec 2012, Teresa Johnson wrote:
>
>> On Wed, Dec 12, 2012 at 2:21 AM, Steven Bosscher
>> wrote:
>> > On Wed, Dec 12, 2012 at 6:07 AM, Aldy Hernandez wrote:
>> >> I don't know how much of this is a fool's errand, and if we want t
On Wed, 12 Dec 2012, Teresa Johnson wrote:
> On Wed, Dec 12, 2012 at 2:21 AM, Steven Bosscher
> wrote:
> > On Wed, Dec 12, 2012 at 6:07 AM, Aldy Hernandez wrote:
> >> I don't know how much of this is a fool's errand, and if we want to commit
> >> to supporting < GCC 3.4, but your patch suggested
On Wed, Dec 12, 2012 at 03:11:26PM +0100, Steven Bosscher wrote:
> There are several warts that need addressing for GCC 4.9. I'm aware of
> the following bugs. There may be others, if you find any please let me
> know.
Ok, in case I find something, I'll let you know.
> 1. dumping for debug_dot_c
On 12/12/2012 02:57 AM, Richard Biener wrote:
> That looks wrong. Having both TYPE_PACKED and TYPE_ALIGN != BITS_PER_UNIT
> is inconsistent, so this part of the patch should not be necessary.
No, that is the only way to give a 4 byte int 2 byte alignment:
use both packed and aligned attributes.
On Wed, Dec 12, 2012 at 2:21 AM, Steven Bosscher wrote:
> On Wed, Dec 12, 2012 at 6:07 AM, Aldy Hernandez wrote:
>> I don't know how much of this is a fool's errand, and if we want to commit
>> to supporting < GCC 3.4, but your patch suggested c++98, and GCC 3.2 claims
>> such.
>
> GCC 3.2 claims
Il 12/12/2012 15:41, H.J. Lu ha scritto:
> MAKEOVERRIDES is used for multilib. I got
>
> /bin/sh ../libtool --tag=CXX --mode=compile -D_GNU_SOURCE -D_DEBUG
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -DASAN_HAS_EXCEPTIONS=1 -DASAN_FLEXIBLE_MAPPING_AND_OFFSET=0
> -
On Wed, Dec 12, 2012 at 3:39 PM, Yuri Rumyantsev wrote:
> Guys,
>
> I assume that this is not right way for fixing such simple performance
> anomaly since we need to do redundant work - combine load to
> conditional and then split it back in peephole2? Does it look
> reasonable? Why we should prod
On Wed, Dec 12, 2012 at 12:49 AM, Paolo Bonzini wrote:
> Il 11/12/2012 22:39, H.J. Lu ha scritto:
>> On Tue, Dec 11, 2012 at 6:36 AM, Paolo Bonzini wrote:
>>> Il 11/12/2012 14:47, H.J. Lu ha scritto:
On Thu, Dec 6, 2012 at 7:07 AM, H.J. Lu wrote:
> On Thu, Nov 29, 2012 at 10:30 AM, H.J.
Guys,
I assume that this is not right way for fixing such simple performance
anomaly since we need to do redundant work - combine load to
conditional and then split it back in peephole2? Does it look
reasonable? Why we should produce non-efficient instrucction that must
be splitted later?
Best re
On Tue, Dec 11, 2012 at 5:49 PM, Lawrence Crowl wrote:
> Convert tree-vectorizer.h'_loop_vec_info::peeling_htab from htab_t
> to hash_table.
>
> * tree-vectorizer.h
>
> New struct peel_info_hasher.
>
> * tree-vect-loop.c
>
> Update dependent calls and types to match.
>
> * tree-vect-data-refs.c
>
On Tue, Dec 11, 2012 at 5:46 PM, Lawrence Crowl wrote:
> Update various htab_t tables to hash_table. Each file is independent.
> Update dependent calls and types.
>
> * tree-ssa-strlen.c'decl_to_stridxlist_htab
>
> Fold decl_to_stridxlist_hash into new struct stridxlist_hasher.
>
> * tree-ssa-loo
On Tue, Dec 11, 2012 at 5:44 PM, Lawrence Crowl wrote:
> Convert tree-sra.c'candidates from htab_t to hash_table.
>
> Fold uid_decl_map_hash and uid_decl_map_eq into new struct
> uid_decl_hasher. This change moves the definitions from tree-ssa.c
> into tree-sra.c and removes the declarations from
On Wed, 12 Dec 2012, Steven Bosscher wrote:
> On Wed, Dec 12, 2012 at 3:08 PM, Richard Biener wrote:
> > Well, it now uses dominators - so steven, I suppose "fancy" dumping
> > should be disabled whenever they are not already computed?
>
> Uh, it does? I tried to avoid that (I used get_loop_body_
On Thu, Nov 29, 2012 at 9:38 AM, H.J. Lu wrote:
> Hi,
>
> When GCC is configured with --with-build-config="bootstrap-asan", all
> -flto tests will fail since -fsanitize=address is used to compile
> liblto_plugin.so and linker isn't compiled with -fsanitize=address.
> This patch filters out -fsanit
On Thu, Nov 29, 2012 at 9:40 AM, H.J. Lu wrote:
> Hi,
>
> When GCC is configured with --with-build-config="bootstrap-asan", all
> -flto tests will fail since -fsanitize=address is used to compile host
> libiberty, which is used to create liblto_plugin.so, and linker isn't
> compiled with -fsanitiz
On Wed, Dec 12, 2012 at 3:08 PM, Richard Biener wrote:
> Well, it now uses dominators - so steven, I suppose "fancy" dumping
> should be disabled whenever they are not already computed?
Uh, it does? I tried to avoid that (I used get_loop_body_in_bfs_order
for this reason). Do you have a test case
On Wed, Dec 12, 2012 at 2:53 PM, Marek Polacek wrote:
> On Wed, Dec 12, 2012 at 01:53:53PM +0100, Richard Biener wrote:
>>
>> This adds the function print_graph_cfg that you can call from a
>> gdb session and directly pipes a dot representation of the
>> function to 'dot -Tx11'. The only change ne
On Wed, 12 Dec 2012, Marek Polacek wrote:
> On Wed, Dec 12, 2012 at 01:53:53PM +0100, Richard Biener wrote:
> >
> > This adds the function print_graph_cfg that you can call from a
> > gdb session and directly pipes a dot representation of the
> > function to 'dot -Tx11'. The only change needed t
Hi,
I checked in this patch to sync config.sub with src.
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 194447)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2012-12-12 Jan-Benedict Glaw
+
+ * config.sub: Merge f
On Wed, Dec 12, 2012 at 01:53:53PM +0100, Richard Biener wrote:
>
> This adds the function print_graph_cfg that you can call from a
> gdb session and directly pipes a dot representation of the
> function to 'dot -Tx11'. The only change needed to the now very
> good dumping code is splitting out t
On Wed, Dec 12, 2012 at 1:53 PM, Richard Biener wrote:
>
> This adds the function print_graph_cfg that you can call from a
> gdb session and directly pipes a dot representation of the
> function to 'dot -Tx11'. The only change needed to the now very
> good dumping code is splitting out the actual
Jason Merrill writes:
> I'd also like to move the scan and PACK_EXPANSION_EXTRA_ARGS code back
> out of the loop.
Like this?
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* pt.c (argument_pack_element_is_expansion_p)
(make_argument_pack_select, scan_parm_packs_and
On Wed, Dec 12, 2012 at 1:55 PM, Uros Bizjak wrote:
> On Wed, Dec 12, 2012 at 12:44 PM, Richard Biener
> wrote:
>
>>> This fix is aimed to remove performance degradation introduced by new
>>> LRA phase that in fact is combining problem. Gcc combiner does
>>> propagation of memory load to if-then-
This patch from Zdenek removes special code handling the forced
rewrite of the original BIV definition. The code was broken,
so simply fallback to the general rewriting code which works fine.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
(the issue is latent on the branch
On Wed, Dec 12, 2012 at 12:44 PM, Richard Biener
wrote:
>> This fix is aimed to remove performance degradation introduced by new
>> LRA phase that in fact is combining problem. Gcc combiner does
>> propagation of memory load to if-then-else gimple that was splitted
>> back by old reload phase. LR
This adds the function print_graph_cfg that you can call from a
gdb session and directly pipes a dot representation of the
function to 'dot -Tx11'. The only change needed to the now very
good dumping code is splitting out the actual worker without
the FILE handling.
Probably not suitable for tru
On Wed, Dec 12, 2012 at 1:17 PM, Steven Bosscher wrote:
> I'll resubmit for GCC 4.9. Instead of a test case, I have a verifier
> queued that asserts no BARRIERs appear in the insns stream when in
> cfglayout mode. (This verifier currently breaks hot-cold partitioning
> all over the place due to a b
Hi Richard,
I assume that this fix does not affect on code size since such pattern
happens very rare although I can add a check on it if you insist.
Register pressure is not a issue here since I assume that additional
fill won't affect on performance as cmove with memory operand. I
decided to not
On Wed, Dec 12, 2012 at 1:08 PM, Steven Bosscher wrote:
> On Wed, Dec 12, 2012 at 11:46 AM, Richard Biener wrote:
>> On Tue, Dec 11, 2012 at 8:57 PM, Steven Bosscher wrote:
>> I'm not sure we want to give up this:
>>
>> @@ -863,12 +863,13 @@ get_loop_body_in_dom_order (const struct loop *loo
>>
On Wed, Dec 12, 2012 at 11:48 AM, Jakub Jelinek wrote:
>> The fixup_reorder_chain patch fixes and ICE with hot-cold partitioning
>> and GCAC checking. A BARRIER is removed somewhere along the line, but
>> the BB_FOOTER pointer still points to it. I'm not sure how things go
>> bad from there, but we
On Wed, Dec 12, 2012 at 12:47 PM, Yuri Rumyantsev wrote:
> Hi Uros,
>
> This fix is for all x86 platforms, we tested it on core2/corei7,
> atom/atom2 and AMD and got performance improvement +6% -- +11%. So I
> don' think we need to introduce additioanl tune feature.
>
> Sorry for my typo with gcc
On Wed, Dec 12, 2012 at 11:46 AM, Richard Biener wrote:
> On Tue, Dec 11, 2012 at 8:57 PM, Steven Bosscher wrote:
> I'm not sure we want to give up this:
>
> @@ -863,12 +863,13 @@ get_loop_body_in_dom_order (const struct loop *loo
>basic_block *tovisit;
>int tv;
>
> + if (loop->latch == EX
Hi Uros,
This fix is for all x86 platforms, we tested it on core2/corei7,
atom/atom2 and AMD and got performance improvement +6% -- +11%. So I
don' think we need to introduce additioanl tune feature.
Sorry for my typo with gcc version - I ment mainline only since 4.7
does not use LRA.
Thanks.
Yu
On Wed, Dec 12, 2012 at 12:27 PM, Yuri Rumyantsev wrote:
> Hi All,
>
> This fix is aimed to remove performance degradation introduced by new
> LRA phase that in fact is combining problem. Gcc combiner does
> propagation of memory load to if-then-else gimple that was splitted
> back by old reload p
On Wed, Dec 12, 2012 at 12:27 PM, Yuri Rumyantsev wrote:
> This fix is aimed to remove performance degradation introduced by new
> LRA phase that in fact is combining problem. Gcc combiner does
> propagation of memory load to if-then-else gimple that was splitted
> back by old reload phase. LRA d
Hi All,
This fix is aimed to remove performance degradation introduced by new
LRA phase that in fact is combining problem. Gcc combiner does
propagation of memory load to if-then-else gimple that was splitted
back by old reload phase. LRA does not perform such splitting. To
avoid performance slowd
On Wed, Dec 12, 2012 at 12:59 AM, Etienne Le Sueur wrote:
> Hi Richard,
>
> Thanks for your reply.
>
> The sysroot of /dev/null is basically to force the user or build system to
> pass a valid --sysroot argument. This helps us to ensure that we only link
> against known libraries (that are in a sp
1 - 100 of 120 matches
Mail list logo
