On 29 September 2011 17:30, Ramana Radhakrishnan
wrote:
> On 19 September 2011 08:54, Ira Rosen wrote:
>
>>
>> Bootstrapped on powerpc64-suse-linux, tested on powerpc64-suse-linux
>> and arm-linux-gnueabi
>> OK for mainline?
>
> Sorry I missed this patch. Is there any reason why we need unspecs i
>
> Early inline can be important for FDO performance reasons -- as inline
> instances get 'context' sensitive profile data.
Yep, early inlining combine well with FDO.
> > Inlining alone does not mess up the line info, but most
> > optimizations we have in early optimization queue do.
>
> Inlin
>
> I believe Richi opent PR back when he introduced the SSA profiling, but I
> don;t seem
> to be able to find it now.
Ha, you found it. It is PR gcov-profile/45890.
Given outcome of this dicussion I think it would make most sense to make
coverage just after into-SSA
(and perhaps arrange cfgcl
On Sun, 2 Oct 2011, Paolo Carlini wrote:
> Hi,
>
> this minor issue remained open and miscategorized as C++ for many years. I
> changed it tentatively to preprocessor and I think we can easily resolve it as
> suggested by submitter: apparently there is a small memory leak happening at
> beginning
On 10/01/2011 08:05 PM, Gabriel Dos Reis wrote:
It is weird though that GCC does not maintain a properly typed
internal representation.
Huh? Different typedefs need to be compared with same_type_p rather
than ==. I don't see how that makes the representation not properly typed.
Jason
Hi,
the inline analysis is called several times and thus it is needed to rest
all the data instead of cumulating them.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 179426)
+++ C
Hi,
GNU LD has bug about reporting references to hidden symbol sthat has been
optimized out.
This however made me notice that we do output into LTO symbol tables things
that do
not belong there. In partiuclar we often output extern inline functions that
has been
fully inlined by early opts.
This
On Sun, Oct 2, 2011 at 4:33 PM, Jan Hubicka wrote:
> * cgraphunit.c (ipa_passes): Remove unrechable nodes.
> * lto-streamer-out.c (produce_symtab): Skip unused extern declarations.
> * ipa.c (cgraph_remove_unreachable_nodes): Do not assume that external
> functions are
> > Index: tree-sra.c
> > ===
> > *** tree-sra.c (revision 179423)
> > --- tree-sra.c (working copy)
> > *** modify_function (struct cgraph_node *nod
> > *** 4622,4627
> > --- 4622,4628
> > VEC (cgraph_edge_p
On Wed, Sep 28, 2011 at 11:10 AM, Jiangning Liu wrote:
> 4) There are over 300 TARGET HOOKS being defined in target.def. I don't
> think adding this interface is hurting GCC.
The reason why there are so many, is because everyone thinks what you
state here ;-)
Ciao!
Steven
On Sun, Oct 2, 2011 at 7:37 AM, Jason Merrill wrote:
> On 10/01/2011 08:05 PM, Gabriel Dos Reis wrote:
>>
>> It is weird though that GCC does not maintain a properly typed
>> internal representation.
>
> Huh? Different typedefs need to be compared with same_type_p rather than
> ==. I don't see h
On 16.09.2011 01:08, Mikael Morin wrote:
How are cobounds passed to a coarray dummy?
For explicit shape, assumed-size and assumed shape coarrays: The value
is not passed but is set for the dummy argument. While that's not
surprising for explicit shape/assumed shape arrays, e.g.
integer ::
On 10/02/2011 12:10 PM, Gabriel Dos Reis wrote:
The comment wasn't about comparison of typedefs -- the patch did not compare
typedefs.
*Value* representations should not change just because a type name was
introduced via a typedef.
Values (and expressions in general) have types. If the type
On Sun, Oct 2, 2011 at 11:51 AM, Jason Merrill wrote:
> On 10/02/2011 12:10 PM, Gabriel Dos Reis wrote:
>>
>> The comment wasn't about comparison of typedefs -- the patch did not
>> compare
>> typedefs.
>
>> *Value* representations should not change just because a type name was
>> introduced via a
Hi.
This patch removes obsolete OUTPUT_ADDR_CONST_EXTRA macro from the CRIS
back end in the GCC and introduces equivalent TARGET_OUTPUT_ADDR_CONST_EXTRA
target hook.
Regression tested on cris-axis-elf.
OK to install?
* config/cris/m32c.c (cris_output_addr_const_extra): Make st
PR 49969 showed a mismatch between the short sync expanders and their
associated insns: the former allowed zero operands but the predicates
in the latter didn't.
Tested on mips64-linux-gnu and applied.
Richard
gcc/
PR target/49696
* config/mips/sync.md (sync__12): Allow zero ope
As discussed recently, this patch adds the stack barriers that are
missing from MIPS' prologue and epilogue patterns. The attached
testcase failed before but passes afterwards.
Tested on mips64-linux-gnu and applied. Thanks to Jiangning
for highlighting the problem.
Richard
gcc/
* con
Hi.
This patch removes obsolete OUTPUT_ADDR_CONST_EXTRA macro from the M68K
back end in the GCC and introduces equivalent TARGET_OUTPUT_ADDR_CONST_EXTRA
target hook.
Compiled without error. Not tested.
OK to install?
* config/m68k/m68k.c (m68k_output_addr_const_extra): Make s
This patch fixes a testsuite problem after my recent patch to be
more picky about -mlong* options.
Tested on mips64-linux-gnu and applied.
Richard
gcc/testsuite/
PR target/50579
* gcc.target/mips/mips.exp (mips_long32_abi_p, mips_long64_abi_p):
New procedures.
(
On Mon, 5 Sep 2011, David Miller wrote:
>> Should we use GNU/Linux in those three cases per the standing request
>> from RMS? I can make the change if so.
> I'm completely ambivalent, feel free to make the change.
Okay, so I went ahead (with some delay, ahem) and applied the patch
below.
Thanks,
Hi David,
On Sun, 4 Sep 2011, David Miller wrote:
> * config/sparc/driver-sparc.c: Correct Linux strings.
would a patch like the one below be appropriate (with a ChangeLog entry),
or is the Linux kernel (or GNU/Linux userland) really using Sparc instead
of SPARC in those places?
Gerald
Anatoly Sokolov writes:
> * config/m68k/m68k.c (m68k_output_addr_const_extra): Make static.
> (TARGET_OUTPUT_ADDR_CONST_EXTRA): Define.
> * config/m68k/m68k.h (OUTPUT_ADDR_CONST_EXTRA): Remove.
> * config/m68k/m68k-protos.h (m68k_output_addr_const_extra): Remove.
This patch implements the extension voted in with paper N2555, after the
initial implementation of variadic templates in GCC. Under this
extension, a template argument list can contain a pack expansion even if
the template has a fixed parameter list. For example,
template struct foo {};
temp
The template and non-template versions of this test run into different
bugs: the template version crashes in noexcept checking because the
initializer hasn't been instantiated, and the non-template version
crashes in fixed_type_or_null because current_function_decl is null.
Tested x86_64-pc-li
At Wed, 21 Sep 2011 02:34:22 +0300,
Ville Voutilainen wrote:
>
> On 21 September 2011 02:18, Ville Voutilainen
> wrote:
> > Ok, a new patch:
> I just noticed that I have tabs disabled. You may want to tabify the patch.
Tabified and rebased on top of the nsdmi changes. Changelog
unchanged.
diff
From: Gerald Pfeifer
Date: Sun, 2 Oct 2011 23:11:14 +0200 (CEST)
> On Sun, 4 Sep 2011, David Miller wrote:
>> * config/sparc/driver-sparc.c: Correct Linux strings.
>
> would a patch like the one below be appropriate (with a ChangeLog entry),
> or is the Linux kernel (or GNU/Linux userland)
This is a patch Richard came up with earlier this year when I had him
look into some excessive sign/zero extensions the compiler was making
on sparc 64-bit.
I finally got around to validating this patch and while doing so noticed
that we've had the instruction attributes screwed up on shifts for
From: David Miller
Date: Sun, 02 Oct 2011 20:50:22 -0400 (EDT)
> * config/sparc/sparc.md (ashlsi3, *ashldi3_sp64): Remove
> conditional insn type setting, we always emit a shift.
> (*ashlsi3_extend, *lshrsi3_extend0): New patterns.
> (*lshrsi3_extend): Rename to *lshrsi3_e
OK. Here is a new diff that hopefully takes into account all of Jason's and
Benjamin's comments. Benjamin's TR2 build patch is not repeated (or tested!)
here. Benjamin, I'd really appreciate if you wouldn't mind confirming I handled
that correctly in tr2/type_traits (Including the inclusion of s
> Date: Sun, 2 Oct 2011 21:36:50 +0400
> From: Anatoly Sokolov
> OK to install?
>
> * config/cris/m32c.c (cris_output_addr_const_extra): Make static.
> (TARGET_OUTPUT_ADDR_CONST_EXTRA): Define.
> * config/cris/cris.h (OUTPUT_ADDR_CONST_EXTR
The range for code tries to do type deduction for the range for
variables when the initializer isn't type dependent, but we don't do
auto deduction from an initializer-list, so we shouldn't try to do that
for range for, either; if we do we end up complaining about an
incomplete type.
Tested x
Someone sent me a variadic templates testcase that was using an
unreasonable amount of memory; -fmem-report showed that half of the
garbage was from ARGUMENT_PACK_SELECT nodes. There's no reason why we
should allocate a new node for each pack on each iteration of the
expansion; we can just all
企业白领核心办公技能（PPT+Excel）
时间地点：2011年10月20-21日 北京
时间地点：2011年10月22-23日 深圳
时间地点：2011年10月28-29日 上海
费用：2600元/人（提供讲义、午餐、发票、茶点等）
授课对象：总经理，各部门主管，财务部、市场部、营销部等相关部门工作人员
咨询电话：020-80560638；020-85917945 谢小姐（不需要此类信件请回复电邮至chinammc2...@126.com退信）
---
From: Richard Henderson
Date: Fri, 30 Sep 2011 14:03:52 -0700
> On 09/30/2011 12:59 AM, David Miller wrote:
>>
>>[ VIS 2.0 bmask patterns ]
>
> I think this is wrong. I think you want to model this as
>
> [(set (match_operand:DI 0 "register_operand" "=r")
> (plus:DI (match_operand:DI
From: Andi Kleen
Currently when reading in LTO sections from ld -r files they can
get randomly reordered based on hash tables and random IDs.
This causes reordering later when the final code is generated and
also makes crashes harder to reproduce.
This patch maintains explicit lists based on the
35 matches
Mail list logo
