On Mon, Apr 18, 2011 at 05:54:28PM +0200, Rainer Orth wrote:
> As already done for the g++.dg/guality driver, I'm also disabling the
> remaining guality testsuites on Tru64 UNIX: the gcc.dg one doesn't even
> start:
>
> gdb: took too long to attach
>
> and the gfortran tests either fail or are un
On Tue, Apr 19, 2011 at 02:06:13PM -0700, Steve Kargl wrote:
> On Mon, Apr 18, 2011 at 05:54:28PM +0200, Rainer Orth wrote:
> > As already done for the g++.dg/guality driver, I'm also disabling the
> > remaining guality testsuites on Tru64 UNIX: the gcc.dg one doesn't even
> > start:
> >
> > gdb:
> Hi, Insane value profile data may contain indirect call targets with
> wrong (corrupted) pids. r172276 solves the problem when the pid
> refers to a bogus target that is still 'alive'. This patch addresses
> the issue when the bogus target is already eliminated or pid is too
> large.
>
> OK aft
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Tuesday, April 19, 2011 2:13 PM
> To: Weddington, Eric
> Cc: Richard Henderson; gcc-patches@gcc.gnu.org; Denis Chertykov; Anatoly
> Sokolov
> Subject: Re: [Patch,AVR]: PR18145: do_copy_data & do_clear_bss only if
This patch to the Go frontend uses the backend interface for temporary
variables. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2011-04-19 Ian Lance Taylor
* go-gcc.cc (Gcc_backend::temporary_variable): New function.
Index: gcc/go/go-gc
Hi,
gcc.dg/torture/pr37868.c fails on SH because of unaligned accesses.
The patch below skips the test as is done for sparc targets.
It's tested with bootstrap and regtest on i686-pc-linux-gnu.
Applied on trunk.
Regards,
kaz
--
2011-04-19 Kaz Kojima
PR testsuite/48676
On Tue, Apr 05, 2011 at 05:55:33PM +0200, Michael Matz wrote:
> I have a preference in having just one DECL_RTL field for conceptual
> reasons:
>
> Most DECLs are actually objects (there are some prominent exceptions, but
> those always would be better described with something like NAMED_ENTITY,
I can not review tree.c changes. I would probably suggest making crc_byte
inline.
> +#if IN_LIBGCOV
> +
> +/* These functions are guarded by #if to avoid compile time warning. */
> +
> +/* Return the number of words STRING would need including the length
> + field in the output stream itself.
On Tue, Apr 19, 2011 at 2:38 PM, Jan Hubicka wrote:
>> Hi, Insane value profile data may contain indirect call targets with
>> wrong (corrupted) pids. r172276 solves the problem when the pid
>> refers to a bogus target that is still 'alive'. This patch addresses
>> the issue when the bogus target
All the statements have now been converted to use the backend interface.
This patch changes the Statement class to use the backend interface,
replacing the get_tree method with get_backend. This basically removes
a bunch of calls to a temporary helper function to convert from
Bstatement to tree.
Hi,
this finishes the planned ipa-inline.c breakup. The transformation code
is actually quite self contained and separated from heuristics, so ipa-inline.c
now hopefully reads pretty well.
At the way I also revisited comments and dropped the cgraph_ prefixes, like
elsewhere.
Bootstrapped/regtest
Am 19.04.2011 20:17, schrieb Janne Blomqvist:
Now that Jim Meyering has remove the macro that prevented directly
calling free(), and replaced gfc_free() with free(), we can fix this.
Committed as obvious.
Thanks Janne. I had meant to do this, but hadn't gotten a round tuit.
Thomas
>
> Why is VEC any better in terms of density ? Are you suggesting using a
> hash table?
It is not any better, but we usually use VEC for variably sized arrays like
this one. Not that I would be big fan of its API, but at least it fives
bounds checking that would catch bugs like one you are fixin
So between hashtab and VEC, which one do you prefer? Either one is fine with me.
Thanks,
David
On Tue, Apr 19, 2011 at 3:39 PM, Jan Hubicka wrote:
>>
>> Why is VEC any better in terms of density ? Are you suggesting using a
>> hash table?
> It is not any better, but we usually use VEC for varia
> Hi,
>
> I have a backlog of random improvements to the WPA phase of LTO
> compilations, all with the common goal of reducing peak memory usage. I
> was basically dumping all trees that the WPA phase read in, and then tried
> to think about which trees can be merged with already existing ones
> So between hashtab and VEC, which one do you prefer? Either one is fine with
> me.
I would go with VEC. While the array will have holes, there are not many since
the ids are originally assigned sequentially.
Actually given that we do IPA pass now, I think you can just remove cgraph->pid
field
On 04/19/2011 12:07 AM, Jakub Jelinek wrote:
On Mon, Apr 18, 2011 at 03:33:18PM -0700, Jason Merrill wrote:
Well, it means that we do dynamic adjustment at runtime. If we're
able to do devirtualization, we should be able to figure out the
right offset as well, just not in 4.6.
Sure, but how
On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka wrote:
>> So between hashtab and VEC, which one do you prefer? Either one is fine with
>> me.
>
> I would go with VEC. While the array will have holes, there are not many
> since
> the ids are originally assigned sequentially.
>
> Actually given that
This patch to the Go frontend adjusts statement.cc so that it no longer
includes any gcc headers. All operations are now done via the backend
interface. There are four remaining files which includes gcc header
files: export.cc, expressions.cc, gogo-tree.c, and types.cc. This patch
bootstrapped a
> On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka wrote:
> >> So between hashtab and VEC, which one do you prefer? Either one is fine
> >> with me.
> >
> > I would go with VEC. While the array will have holes, there are not many
> > since
> > the ids are originally assigned sequentially.
> >
> > A
On Tue, Apr 19, 2011 at 4:30 PM, Jan Hubicka wrote:
>> On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka wrote:
>> >> So between hashtab and VEC, which one do you prefer? Either one is fine
>> >> with me.
>> >
>> > I would go with VEC. While the array will have holes, there are not many
>> > since
> Actually, among all the choices, funcdef_no is probably the most dense
> one -- it is for function decl with definition only. In LIPO, the
Yes, funddef_no is densiest, but we don't really need great density here
(in many other places we index arrays by cgraph_uid - it is intended for
that purpo
On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka wrote:
>> Actually, among all the choices, funcdef_no is probably the most dense
>> one -- it is for function decl with definition only. In LIPO, the
>
> Yes, funddef_no is densiest, but we don't really need great density here
> (in many other places w
duplicate_decls was dropping DECL_DISREGARD_INLINE_LIMITS, but leaving
the always_inline attribute in DECL_ATTRIBUTES, leading to confusion.
This patch keeps them in sync.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.5 (not 4.6).
commit 679e5e90918506d6792b8c0b19deff0f1a497298
Author: Ja
On Tue, Apr 19, 2011 at 12:19 PM, Diego Novillo wrote:
> On Tue, Apr 19, 2011 at 15:02, Easwaran Raman wrote:
>> This makes the gcc driver pass the --save-temps option to the assembler or
>> assembler wrapper so that post-assembly tools like MAO can be integrated.
>> Bootstraps on x86_64. Ok fo
> On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka wrote:
> >> Actually, among all the choices, funcdef_no is probably the most dense
> >> one -- it is for function decl with definition only. In LIPO, the
> >
> > Yes, funddef_no is densiest, but we don't really need great density here
> > (in many ot
Hi,
This patch allows variables whose type transitively contains a union to share
stack slots if -fno-strict-aliasing is used.
Bootstraps on x86_64 with no test regressions. Also tested by changing
flag_strict_aliasing to 0 by default. Bootstraps and no test regressions when
compared to flag
Hi,
while cleaning up the way small functions inliner populate the heap I made
simple
thinko trying to compute summary information used for badness and the badness
values themselves in one loop. Since only FDO badness computation depends on
summaries
this has passed my non-FDO testing.
profileb
Committed the following after regression testing. i will update the test case
when I get the chance.
Jerry
Author: jvdelisle
Date: Wed Apr 20 04:18:25 2011
New Revision: 172753
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172753
Log:
2011-04-19 Jerry DeLisle
PR libgfortran/486
On Apr 19, 2011, at 11:12 AM, Rainer Orth wrote:
> I've had a closer look now and think it's possible (and desirable) to
> define HAVE_GAS_HIDDEN for Darwin, too.
But, they don't have the same thing, therefore, either, you loose out on the
meaning, or, you must have yet another test that means th
On Apr 19, 2011, at 10:29 AM, Georg-Johann Lay wrote:
> Thanks for that hint. There are some more test cases that imply int >=
> 32 bit
>
> Johann
>
> 2011-04-19 Georg-Johann Lay
>
> * gcc.dg/pr42629.c: Add dg-require-effective-target int32plus
> * gcc.c-torture/execute/cmpsi-2.c:
On Apr 19, 2011, at 2:59 PM, Kaz Kojima wrote:
> gcc.dg/torture/pr37868.c fails on SH because of unaligned accesses.
> The patch below skips the test as is done for sparc targets.
I'd pre-approve hoisting these up into the lib/.exp files and checking a
generic target requirement... :-)
> -/* {
In this bug, the underlying problem was that we had a COMPLEX_EXPR
representing a complex constant rather than a COMPLEX_CST. There was
also the issue that 4.5 didn't deal with this very well, but fixing the
testcase to use COMPLEX_CST (by folding the COMPLEX_EXPR case like we do
everything el
101 - 133 of 133 matches
Mail list logo
