Steve Ellcey writes:
> On Tue, 2012-12-11 at 21:52 +, Richard Sandiford wrote:
>
>> > + mips_dbx_regno[CPRESTORE_SLOT_REGNUM] = IGNORED_DWARF_REGNUM;
>
>
>> If even fake registers like these are going to be used, then I think
>> we should initialise to IGNORED_DWARF_REGNUM rather than INVALID
Ping.
Could someone please have a look?
--
Maxim Kuznetsov
> Thanks for the explanation, now I understand it. I fixed the patch
> according to your remarks. I removed %| support since we don't
> actually need it in i386 right now, it was added for the purpose of
> possible generalization.
>
> Upd
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. Lu wrote:
> Hi,
>
> Since libsanitizer is used f
Il 11/12/2012 23:00, H.J. Lu ha scritto:
> ## The mysterious backslash in the grep pattern is consumed by make.
> -lib_gnu_awt_xlib_la_LDFLAGS = ../libstdc++-v3/src/libstdc++.la \
> +lib_gnu_awt_xlib_la_LDFLAGS = $(LIBSTDCXX_RAW_CXX_LDLAGS) \
> @X_PRE_LIBS@ @X_LIBS@ -lX11 @X_EXTRA_LIBS@ \
>
On Tue, 11 Dec 2012, Jakub Jelinek wrote:
> Hi!
>
> The following testcase on x86_64 (or the f90-intrinsic-bitsize.f on 32-bit
> HWI) with -Os shows a bug in discover_iteration_bound_by_body_walk. If some
> bound is a -1, -1 HWI, then adding double_int_one to it overflows into 0, 0
> HWI and we
On Tue, 11 Dec 2012, Jakub Jelinek wrote:
> Hi!
>
> Lately this testcase often timesout for me on a busy box,
> I don't see a point iterating 2000^3 times, with 400^3 it is much faster
> and I still could reproduce the problem before the corresponding fix
> and the vectorizer r145171 fix fixed it
On Tue, 11 Dec 2012, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, this patch forward ports Steven's patch from 4.7
> branch to trunk. No need to include pointer-set.h (already included),
> I've moved the var definition into the #ifdef so that it isn't an unused
> static var and tweaked
Richard Biener writes:
> * gcc.dg/tree-ssa/ssa-pre-1.c: Adjust.
This was missing in your commit.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Tue, 11 Dec 2012, Aldy Hernandez wrote:
> Hi Richard.
>
> Your last patch for this PR suggested we verify our assumptions wrt a least
> common C++ compiler to build trunk with. Since I already had the offended
> system at hand (Red Hat Linux 8.0), I decided to investigate a bit further.
>
>
On Wed, 12 Dec 2012, Andreas Schwab wrote:
> Richard Biener writes:
>
> > * gcc.dg/tree-ssa/ssa-pre-1.c: Adjust.
>
> This was missing in your commit.
Oops, thanks for noticing and fixing!
Richard.
Hi!
As this will need further changes in the backends (teach them to emit
const data etc. after NOTE_INSN_CALL_ARG_LOCATION if a BARRIER is followed
by such a note), IMHO the cleanups went far over what is desirable for
stage3, thus I'm reverting it for now and will reapply early in 4.9 stage 1,
s
On Thu, Dec 06, 2012 at 01:48:31PM +0100, Steven Bosscher wrote:
> * bitmap.h: Fix "set_difference" references in comment.
> * dse.c (dse_bitmap_obstack): Fix comment.
This is ok.
>
> * loop-invariant.c (record_use): Use DF_REF_REG_MEM_P instead of
> looking at spe
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 many things, but any GCC that has the old C++ parser
has known no
On Wed, Dec 12, 2012 at 11:17 AM, Jakub Jelinek wrote:
>> * cfgrtl.c (rtl_verify_flow_info): Fix code style (indentation).
>
> This is undesirable, we generally don't fix indentation unless you touch
> the code (or very close surrounding code),
OK, I'll drop this then.
>> (fixup
On Tue, Dec 11, 2012 at 6:50 PM, Iyer, Balaji V wrote:
> Hello,
> Did you get a chance to look at this patch? I submitted this ~1 month
> ago, so thought I would inquire its status.
Let me chime in from a release manager POV - I fear this needs to wait for
next stage1, we're way into sta
On Tue, Dec 11, 2012 at 8:57 PM, Steven Bosscher wrote:
> Hello,
>
> This patch clusters loop bodies in the CFG graph dumper. Makes for
> easier-to-interpret plots and helps debugging.
>
> Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
I'm not sure we want to give up this:
@@
On Wed, Dec 12, 2012 at 11:29:28AM +0100, Steven Bosscher wrote:
> >> (fixup_reorder_chain): Set cfg_layout_function_header to NULL to
> >> avoid dangling pointers into GC-allocated insns. Clear BB_HEADER,
> >> BB_FOOTER, and cfg_layout_function_footer for the same reason.
On Tue, Dec 11, 2012 at 11:04 PM, Kai Tietz wrote:
> Hello,
>
> This fixes an old regression about ms-structure-layout in combination
> with packed-attribute.
>
> ChangeLog
>
> 2012-12-11 Kai Tietz
>
> PR c/52991
> * stor-layout.c (start_record_layout): Handle
> packed-att
On Tue, Dec 11, 2012 at 11:53 PM, Xinliang David Li wrote:
> The following the O2 size data from SPEC2k. Note that with push/pop,
> it is a always a net win (negative delta) in terms of total binary or
> total loadable section size.
Thanks for the data!
Richard.
> thanks,
>
> David
>
>
Hi Richard,
is the attached patch ok for ARM?
Bye,
-Andreas-
2012-12-12 Andreas Krebbel
* target.def: Define canonicalize_comparison hook.
* targhooks.h (default_canonicalize_comparison): New prototype.
* targhooks.c (default_canonicalize_comparison): New function.
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
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: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
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
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 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
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: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 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
>>
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: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
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 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 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 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-
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: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
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
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, 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
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, 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 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 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 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 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 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: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
>
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 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.
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
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 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
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 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 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 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 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 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 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
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,
> 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
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
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
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, 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
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
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
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
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
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_
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
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
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
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 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
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
> 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
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 |
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
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
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)
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!
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!
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 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!
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
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
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
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
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 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
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
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
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
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
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
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
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
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
1 - 100 of 120 matches
Mail list logo
