> On Sat, Sep 21, 2013 at 3:51 PM, Xinliang David Li wrote:
> > On Sat, Sep 21, 2013 at 12:54 PM, Jan Hubicka wrote:
> >> Hi,
> >> this is upated version of patch discussed at
> >> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00841.html
> >>
> >> It makes CORE tuning to more follow the optimizati
On Wed, Sep 18, 2013 at 3:45 PM, Zamyatin, Igor wrote:
> Ccing Uros. Changes in i386.md could be related to the fix for PR57954.
> -Original Message-
> From: Wei Mi [mailto:w...@google.com]
> Sent: Thursday, September 12, 2013 2:51 AM
> To: GCC Patches
> Cc: David Li; Zamyatin, Igor
> Sub
> 2013-09-16 Wei Mi
>
> * gcc/config/i386/i386-c.c (ix86_target_macros_internal): Separate
> PROCESSOR_COREI7_AVX out from PROCESSOR_COREI7.
> * gcc/config/i386/i386.c (ix86_option_override_internal): Ditto.
> (ix86_issue_rate): Ditto.
> (ia32_multipass_d
>
> I am not sure if AMD hardware has any limitations here. It fuses only
> cmp/test
This is what Agner Fog says:
A CMP or TEST instruction immediately followed by a conditional jump can be
fused into a single macro-op. This applies to all versions of the CMP and TEST
instructions and all cond
REG_BR_PROB notes are stored as:
(expr_list:REG_BR_PROB (const_int ) )
but a full const_int rtx seems a bit heavweight when all we want is
a plain "int". This patch uses:
(int_list:REG_BR_PROB )
instead.
I didn't bother adding INT_LIST to lists.c because in practice we never
free one exp
Hello Richard,
Not directly related to your patch but...
On Sun, Sep 22, 2013 at 12:54 PM, Richard Sandiford wrote:
> @@ -588,14 +589,17 @@ cond_exec_process_if_block (ce_if_block_
> goto fail;
> #endif
>
> - true_prob_val = find_reg_note (BB_END (test_bb), REG_BR_PROB, NULL_RTX);
> - if
On 20.09.2013 18:46, Jason Merrill wrote:
On 09/19/2013 02:37 PM, Adam Butcher wrote:
+ static int i = 0;
I think this needs to be global and GTY so that it works properly
with PCH.
Didn't consider PCH. This delta OK?
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -28897,12 +28897,12 @@
On 20.09.2013 18:47, Jason Merrill wrote:
Why is canonical_type_parameter not doing the right thing here? I
don't see a reason we should need to treat these differently from
normal template parms.
The issue only happens with indirect parms. The type 'auto' is given a
canonical type in make_au
> Hello Richard,
>
> Not directly related to your patch but...
>
> On Sun, Sep 22, 2013 at 12:54 PM, Richard Sandiford wrote:
> > @@ -588,14 +589,17 @@ cond_exec_process_if_block (ce_if_block_
> > goto fail;
> > #endif
> >
> > - true_prob_val = find_reg_note (BB_END (test_bb), REG_BR_PROB,
Dear Janus,
This is OK for trunk and, in my opinion, for back-porting in its entirity.
Thanks for the patch
Cheers
Paul
On 21 September 2013 16:31, Janus Weil wrote:
> Hi all,
>
> the straightforward patch in the attachment does two things:
>
> 1) It prevents a segfault, which is a regression
>> > http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00884.html
>
> This patch seems resonable. (in fact I have pretty much same in my tree)
> use_vector_fp_converts is actually trying to solve the same problem in AMD
> hardware - you need to type the whole register when converting.
> So it may work w
On 22.09.2013 14:07, Adam Butcher wrote:
On 20.09.2013 18:47, Jason Merrill wrote:
Why is canonical_type_parameter not doing the right thing here? I
don't see a reason we should need to treat these differently from
normal template parms.
The issue only happens with indirect parms. The type '
OK.
Original Message
From: Adam Butcher
Sent: Sun, Sep 22, 2013 08:41 AM
To: Jason Merrill
CC: gcc-patches@gcc.gnu.org
Subject: Re: [C++1y] [PATCH 1/4] Use translation-unit-global rather than
parameter-list-local counter for generic type names to facilitate nested
implic
> You disable fusion for Budozer here sinze you did not add it into
> TARGET_FUSE_CMP_AND_BRANCH_64.
Ok, will add it.
>
> Perhaps we can have TARGET_FUSE_CMP_AND_BRANCH_64 and
> TARGET_FUSE_CMP_AND_BRANCH_32
> plus an macro TARGET_FUSE_CMP_AND_BRANCH that chose corresponding variant
> based
> o
Hi,
Tim Shen ha scritto:
>I think I get it this time :)
>
>Now we have "regex.tcc".
>
>I'll do a full test before committing.
If testing goes well patch is Ok to commit.
Thanks!
Paolo
This fixes an old glitch in the gimplification of asm, present initially for
clobbers and duplicated later for labels as well. The line:
asm ("nop" : : : "eax", "ebx");
is gimplified into:
__asm__ __volatile__("nop" : : : "ebx", "eax", "eax");
in the .gimple file because the TREE_CHAIN o
*PING* http://gcc.gnu.org/ml/fortran/2013-09/msg00031.html
(Additional early ping for:
http://gcc.gnu.org/ml/fortran/2013-09/msg00039.html )
On September 16, 2013 22:18, Tobias Burnus wrote:
I forgot, again, to attach the patch.
However, to my surprise the email made it through. Contrary to
> -Original Message-
> From: Richard Earnshaw
> Sent: Thursday, September 19, 2013 5:13 PM
> To: Zhenqiang Chen
> Cc: 'Richard Biener'; GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
>
> On 18/09/13 10:45, Zhenqiang Chen wrote:
> >
> >> -Original Message-
Hi Jason,
I noticed that, although implicit function template declarations were
accepted. They weren't setup correctly and didn't instantiate properly.
The following patch fixes this by moving finish_fully_implicit_template
to the end of cp_parser_init_declarator. OK to go with the others?
Hi,
The patch fixes PR target/58423.
Bootstrap and no make check regression on Chromebook with ARM mode.
Is it OK for trunk?
Thanks!
-Zhenqiang
ChangeLog:
2013-09-23 Zhenqiang Chen
PR target/58423
* config/arm/arm.c (arm_emit_ldrd_pop): Attach RTX_FRAME_RELATED_P
on INSN.
---
20 matches
Mail list logo
