On Tue, Mar 27, 2012 at 10:59 AM, Richard Guenther wrote:
> On Tue, Mar 27, 2012 at 10:32 AM, Steven Bosscher wrote:
>> On Tue, Mar 27, 2012 at 9:17 AM, Richard Guenther wrote:
>>> It would be nice to finally move
>>> the call to cgraph_finalize_compilation_unit to the
On Tue, Jan 1, 2013 at 6:04 PM, David Edelsohn wrote:
> There are open questions about how to wedge GCC LTO support into the
> AIX XCOFF file format. I am unsure if LTO can be an additional section
> in the XCOFF file or should be new CSECTs in an existing section.
> Maybe CSECTs in the XCOFF comme
On Thu, Jan 3, 2013 at 9:51 PM, Jeff Law wrote:
> On 01/03/2013 12:01 PM, Steven Bosscher wrote:
>>
>> Hello,
>>
>> Consider the following test case:
>>
>> void bar (void);
>> int foo (int b, int c, int d)
>> {
>>int
On Sat, Jan 5, 2013 at 9:10 PM, Steven Bosscher wrote:
> Bootstrapped&tested on powerpc64-unknown-linux-gnu.
And to be clear, bootstrapped with this patch on top:
Index: system.h
===
--- system.h(revision 194924)
+++ s
Hello,
As-is, tree-ssa-sink.c can only sink GIMPLE_ASSIGN statements. This
patch lets tree-ssa-sink.c sink pure calls also.
This allows the pass to sink the call to use in the following test
case (new test case, ssa-sink-10.c to be):
-- 8<
/* { dg-do compile
On Mon, Jan 7, 2013 at 8:45 PM, Jeff Law wrote:
> Before diving into the patch I think we should figure out why we see such
> different effects of eliminating these paths from the CFG. Your assertion
> is eliminating them will result in more false positives and less
> optimization while my assert
On Tue, Jan 8, 2013 at 12:32 PM, Richard Biener wrote:
> Does it handle side-effects on the builtin-unreachable path correctly?
>
> int b;
> int a;
> extern void foo ();
> int main()
> {
> if (!a)
>{
> if (!b)
>foo ();
> __builtin_unreachable ();
>}
> }
>
> ---
>
> void
On Thu, Jan 10, 2013 at 6:31 PM, Marek Polacek wrote:
> + /* We changed the CFG. Recompute irreducible BBs and edges. */
> + mark_irreducible_loops ();
This is a very expensive fix for a really unusual situation.
I don't think this is the right thing to do...
Ciao!
Steven
Hello Vlad,
The attached patch back-ports to the LRA branch (or foward-ports,
depending on how you look at it :-) all the changes made on the trunk
to LRA.
Bootstrapped&tested on powerpc64-unknown-linux-gnu[1] and
ia64-unknown-linux-gnu[2], and cross-built and tested mipsisa64-elf
[3].
[1] http:
On Thu, Jan 17, 2013 at 2:18 PM, Kumar, Venkataramanan wrote:
> Hi Honza,
>
> There is no change when I find top 10 symbols using nm -t d --size-sort ./cc1
> | c++filt | tail.
More interesting would be the output of genautomata with the "-stats" flag.
Ciao!
Steven
Hello Vlad,
Attached is my attempt to fix PR55934, an error recovery issue in LRA
with incorrect constraints in an asm.
I'm not 100% sure this is all correct (especially the LRA insn data
invalidating in lra-assigns.c) but it appears to fix the PR without
introducing test suite failures.
Can you
On Fri, Jan 18, 2013 at 7:25 PM, Vladimir Makarov wrote:
>
> PR target/55433
> * lra-constraints.c (curr_insn_transform): Reuse original insn for
> secondary memory move.
> (inherit_reload_reg): Use rclass instead of cl for
> check_secondary_memory_needed_p.
On Fri, Jan 18, 2013 at 12:59 AM, Jakub Jelinek wrote:
> On Fri, Jan 18, 2013 at 12:45:06AM +0100, Steven Bosscher wrote:
>> --- testsuite/gcc.target/i386/pr55934.c (revision 0)
>> +++ testsuite/gcc.target/i386/pr55934.c (revision 0)
>> @@ -0,0 +1,10 @@
>> +/* PR inline-
On Fri, Jan 18, 2013 at 10:47 PM, Vladimir Makarov wrote:
> LRA branch was merged with trunk @ 195303.
>
> Committed as rev. 195305.
Hi Vlad,
It looks like this merge breaks bootstrap on
powerpc64-unknown-linux-gnu. The compiler goes into an infinite loop
while compiling libdecnumber. I'm trying
On Sat, Jan 19, 2013 at 2:12 PM, Steven Bosscher wrote:
> It looks like this merge breaks bootstrap on
> powerpc64-unknown-linux-gnu. The compiler goes into an infinite loop
> while compiling libdecnumber. I'm trying to create a small test case.
Here it is. Compile with:
$ ./cc1
On Sat, Jan 19, 2013 at 1:15 AM, Vladimir Makarov wrote:
> On 13-01-17 6:45 PM, Steven Bosscher wrote:
>>
>> Hello Vlad,
>>
>> Attached is my attempt to fix PR55934, an error recovery issue in LRA
>> with incorrect constraints in an asm.
>>
>> I'm
On Mon, Jan 21, 2013 at 5:22 PM, Vladimir Makarov wrote:
> I'd prefer the above change than just keeping
> lra_invalidate_insn_data call. I think it is more safe solution for other
> parts of LRA code.
I agree, but unfortunately the compiler does not...
With that lra.c change, I get extra fails:
On Wed, Jan 23, 2013 at 7:43 PM, Vladimir Makarov wrote:
> The error occurs because a pseudo in asm insn is not changed into hard
> register as the pseudo info is incorrect after info updating.
>
> You should just use lra_update_insn_regno_info. The patch (and the patch is
> ok to commit) should lo
On Sun, Jan 27, 2013 at 11:09 PM, Georg-Johann Lay wrote:
The patch was originally worked out by Bernd Schmidt and fixed a problem
introduced in
http://gcc.gnu.org/r190252
Ironically, this revision fixes a reload problem on x86/x86_64 --
which doesn't use reload anymore now...
Hello,
This brings down compile time for fwprop by avoiding CFG changes in
loop_optimizer_init(). The CFG changes it could make would invalidate
the fast dominance queries, so that walk_dominator_tree had to work
with the slow queries -- rather painful on a CFG with an almost flat
dominator tree.
On Wed, Jan 30, 2013 at 12:01 AM, Steven Bosscher wrote:
> To prevent that mistake in the future, I've add an assert in dominance.c.
Hmm, that worked with my release-checking compiler of course, but
fails in at least tree-ssa-dom.c (same as for fwprop.c,
loop_optimizer_init destroys fast
On Wed, Jan 30, 2013 at 6:24 PM, Vladimir Makarov wrote:
> The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56144
>
> The patch was successfully bootstrapped and tested on x86/x86-64.
Hello Vlad,
Can you please put this patch on the lra-branch too, so that the
auto-tester
On Thu, Feb 7, 2013 at 4:09 AM, Alan Modra wrote:
> After fixing PR54009 (again), I thought I'd take a look at why reload
> is generating the following correct but poor code
>
> stw 10,8(1)
> stw 11 12(1)
> ...
> lfd 0,8(1)
> stfd 0,x+32764@l(9)
>
> rather than
>
> addi 9,x+32764@l(9)
> ...
On Fri, Feb 8, 2013 at 12:25 PM, Richard Biener wrote:
>> Steven - can you reproduce your failures (and on which target?)
>
> Ping.
I had ASAN failures on ppc64 but I cannot reproduce them anymore.
Ciao!
Steven
On Wed, Feb 13, 2013 at 4:54 PM, Jakub Jelinek wrote:
> Hi!
>
> As agreed on in the PR, here is the revertion of 3 commits, so that
> PCH works again for -gstabs and other debug info formats for 4.8
> release. For 4.9 we should either remove support for anything non-DWARF, or
> hope somebody steps
On Thu, Feb 14, 2013 at 12:17 AM, John David Anglin wrote:
> On 2013-02-13 3:33 PM, David Edelsohn wrote:
>>
>> Perhaps Dave can explain what would have to be done to move this
>> > platform to DWARF2...?
>> >
>
> I had looked at this a bit in the past. I don't think it's that difficult
>
On Thu, Feb 14, 2013 at 12:48 AM, Jakub Jelinek wrote:
> On Thu, Feb 14, 2013 at 12:41:30AM +0100, Steven Bosscher wrote:
>> > I agree with David that it might be better to give up pch.
>>
>> That'd be a really a good start.
>
> You can do it with say following p
On Wed, Feb 13, 2013 at 10:33 PM, David Edelsohn wrote:
> The AIX system supports DWARF debugging, but GCC does not generate it
> on AIX and GDB does not consume it on AIX.
Is there a description for what has to be done in GCC to enable DWARF
with AIX as/ld? E.g. is it required to support the ".dw
Hello,
Building a cross-compiler from powerpc-linux to powerpc-aix fails with:
../../combined/gcc/collect2.c: In function 'void scan_prog_file(const
char*, scanpass, scanfilter)':
../../combined/gcc/collect2.c:2860:8: error: 'F_LOADONLY' was not
declared in this scope
This is due to:
2013-02-03
On Thu, Feb 14, 2013 at 2:21 PM, Tristan Gingold wrote:
>> Is there a description for what has to be done in GCC to enable DWARF
>> with AIX as/ld? E.g. is it required to support the ".dwsect" pseudo?
>> Is there already a plan from someone to make GCC produce DWARF on
>> AIX7?
>
> Yes, you need to
Hello,
A user sent me a request to give names to the digraph in a graph dump.
This name can be used as a key for the dump, for a tool that can
generate graph metrics to see GCC transforms code as it passes through
the pipeline. Another user requested the same thing for a hacked xdot
that can plot
On Sat, Feb 16, 2013 at 1:55 AM, Vladimir Makarov wrote:
> The branch was merged with trunk @ r196091.
>
> Successfully bootstrapped on x86-64.
>
> Committed as rev. 196099.
Hello Vlad,
It looks like this broke bootstrap on ia64 and
/home/stevenb/lra_powerpc64_autotester/lra-branch/libgfortran/g
On Mon, Feb 18, 2013 at 9:21 PM, Steven Bosscher wrote:
> On Sat, Feb 16, 2013 at 1:55 AM, Vladimir Makarov wrote:
>> The branch was merged with trunk @ r196091.
>>
>> Successfully bootstrapped on x86-64.
>>
>> Committed as rev. 196099.
>
> Hello Vlad,
&g
On Mon, Feb 18, 2013 at 10:29 PM, Steven Bosscher wrote:
>> /home/stevenb/lra_powerpc64_autotester/lra-branch/libgfortran/generated/pow_i8_i4.c:
>> In function 'pow_i8_i4':
>> /home/stevenb/lra_powerpc64_autotester/lra-branch/libgfortran/generated/pow_i8_i4.c:75:1:
&g
Hello,
The attached patch splits a new function df_insn_info_delete from
df_insn_delete. The original motivation was to get rid of the silly
"deleting insn with uid = ..." messages when re-scanning an insn,
because the mentioned insn isn't deleted at all (it's just rescanned).
But it turns out tha
On Thu, Feb 21, 2013 at 10:59 AM, Richard Biener wrote:
> On Thu, Feb 21, 2013 at 1:10 AM, Steven Bosscher wrote:
> +/* Delete all of the refs information from the insn with UID.
> + Internal helper for df_insn_info_delete, df_insn_rescan, and other
>
> df_insn_delete I
On Fri, Feb 22, 2013 at 9:15 PM, Vladimir Makarov wrote:
> LRA branch was merged with trunk @ 196224.
>
> The branch was successfully bootstrapped on x86/x86-64, ppc64, and ia64.
Hello Vlad,
Thanks for the fix and merge.
I still have a large number of FAILs on mipsisa64 that weren't there
before
On Fri, Feb 22, 2013 at 11:26 PM, Vladimir Makarov wrote:
>> I still have a large number of FAILs on mipsisa64 that weren't there
>> before. Compare these two results to see what I mean:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00123.html
>> http://gcc.gnu.org/ml/gcc-testresults/2013-
> This patch corrects these things. Regression-tested.
> OK for trunk? (I will not be able to commit for a few
> days due to business travel, unless somebody is _really_
> fast :-)
Looks OK to me. Fast enough for you?
Ciao!
Steven
On Wed, Nov 2, 2011 at 11:17 PM, Janus Weil wrote:
> What the patch does is to change the return value from
> 'gfc_try' (SUCCESS/FAILURE) to 'match'
> (MATCH_YES/MATCH_NO/MATCH_ERROR). Of course we're not really
> 'matching' anything here, but the yes/no/error range of values is
> exactly what we
Hello,
This patch fixes PR54150. The patch was approved by Richi in Bugzilla,
but I won't commit this for a few days so that others can speak up if
they don't agree.
Ciao!
Steven
PR54150.diff
Description: Binary data
Hello,
SBITMAP_SIZE should be used to get the current size of an sbitmap.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. Will commit as obvious.
Ciao!
Steven
sbitmap_size.diff
Description: Binary data
Hello,
VEC_reserve allocates an *extra* number of slots. There is
unfortunately no VEC_resize op (one of the first things to add after
the merge of the cxx branch, I suppose...), so to "grow" a VEC without
increasing the used slots count (the VEC_length) it's necessary to
compute the number of ext
On Fri, Aug 10, 2012 at 12:15 AM, Richard Henderson wrote:
> On 08/09/2012 03:06 PM, Steven Bosscher wrote:
>> + unsigned old_len = name_to_id ? VEC_length (unsigned, name_to_id) : 0;
>> + VEC_reserve (unsigned, heap, name_to_id, num_ssa_names - old_len);
>
> VEC_l
On Sun, Aug 12, 2012 at 10:09 PM, Diego Novillo wrote:
> This patch implements the configuration changes needed to
> bootstrap with a C++ compiler by default.
Hi,
Is it possible to add -fno-rtti to the default CXX_FLAGS, and remove
it if necessary?
Ciao!
Steven
Hello,
This patch tried to use non-clearing memory allocation where possible.
This is especially important for very large functions, when arrays of
size in the order of n_basic_blocks or num_ssa_names are allocated to
hold sparse data sets. For such cases the overhead of memset becomes
measurable
On Mon, Aug 13, 2012 at 2:34 AM, Diego Novillo wrote:
> On 12-08-12 16:16 , Steven Bosscher wrote:
>>
>> On Sun, Aug 12, 2012 at 10:09 PM, Diego Novillo
>> wrote:
>>>
>>> This patch implements the configuration changes needed to
>>> bootstrap with
Hello,
Checking overhead in dominance.c gives measurable compile time
increases on a set of cc1-i files. Most of the checking should be done
only with non-release checks enabled.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
dom_checking_assert.diff
Description
Hello,
Verifying loop fathers now passes on powerpc64-unknown-linux-gnu.
Also speed up fix_loop_structure by requiring DOM_OK so that fast DOM
queries are available.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
cfg_loop_father.diff
Description: Binary data
On Tue, Aug 14, 2012 at 12:48 PM, Richard Guenther wrote:
> If SPU md reorg would like to look at loop structures it should
> compute them. Simply call flow_loops_find, which hopefully works
> in CFG RTL mode (which I think is the mode available from md reorg?).
No, the CFG is destroyed just bef
Hello,
Many unused timevars, many timevars that measure completely different
passes, passes with the wrong timevar, etc.
Time for a bit of maintenance / janitorial.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
timevar_tlc.diff
Description: Binary data
On Tue, Aug 14, 2012 at 8:40 PM, Diego Novillo wrote:
> On 12-08-14 14:26 , Steven Bosscher wrote:
>>
>> Hello,
>>
>> Many unused timevars, many timevars that measure completely different
>> passes, passes with the wrong timevar, etc.
>>
>&g
On Tue, Aug 14, 2012 at 9:17 PM, Diego Novillo wrote:
> Is 32 the longest we can tolerate?
This 32 is just currently the longest name length of all timevars (for
"straight-line strength reduction"), but there are a few more long
ones ("PCH preprocessor state restore" ...). I didn't look at the
to
On Tue, Aug 14, 2012 at 9:25 PM, Diego Novillo wrote:
>> This 32 is just currently the longest name length of all timevars (for
>> "straight-line strength reduction"), but there are a few more long
>> ones ("PCH preprocessor state restore" ...). I didn't look at the
>> total length of the lines th
On Tue, Aug 14, 2012 at 10:46 PM, Lawrence Crowl wrote:
> You can check the error statically. Something like
>
> % cat limitstring.c
> #define LIMIT 32
>
> struct def {
> int x;
> char name[LIMIT+1];
> };
>
> struct def var[] = {
> { 3, "hello" },
> { 4, "name is much too too long for a r
Hello,
This patch rewrites the rewriting part of
rewrite_into_loop_closed_ssa. This function took ~300s on the
simplified test case for PR54146, walking around the many thousands of
loops in the >400,000 basic blocks in the CFG, in
compute_global_livein.
For rewriting into LC-SSA, we can do bette
On Mon, Aug 6, 2012 at 1:27 PM, Paolo Bonzini wrote:
>> 2. sparseset has the same problem of memory clearing (for valgrind,
>> see sparseset_alloc).
>
> ... only the sparse array needs this clearing, but currently we do it
> for both.
And according to the fat comment before the xcalloc, it's not
On Thu, Aug 16, 2012 at 2:56 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 15 Aug 2012, Steven Bosscher wrote:
>
> Please convince me that this :
>
> +/* Return the outermost superloop LOOP of USE_LOOP that is a superloop of
> + both DEF_LOOP and USE_LOOP. */
>
On Thu, Aug 16, 2012 at 4:24 PM, Michael Matz wrote:
> Btw, then the comment is still wrong. You're returning the innermost
> common outer loop, not the outermost (which would be trivial).
I'll fix the comment.
Ciao!
Steven
Hello,
This reduces peak memory usage for the small test case of PR54146 by
2GB. 24hrs ago peak memory was 9.4 GB in top, but with Richi's patches
from yesterday and with this one, peak memory is now "only" 5.2GB.
About 40% of that is in IRA and reload so there is still room for
improvement, but c
Hello,
On a 64-bits host we leave 32 bits of each bitmap_element unused. And
actually, on a 32-bits host we do that too for GGC-allocated bitmaps
(due to alignment).
With this patch, we use those 32 bits by making BITMAP_WORD an
unsigned int (instead of unsigned long) and having 5 elts per
bitmap
On Fri, Aug 17, 2012 at 1:54 PM, Richard Guenther
wrote:
> Well, another effect of reducing the size of BITMAP_WORD is that
> operations are not performed in a mode optimally using CPU regs
> (did you check code generation differences on a 64bit host?).
I did, on x86_64 and on powerpc64. The effe
On Fri, Aug 17, 2012 at 2:21 PM, Jakub Jelinek wrote:
> On Fri, Aug 17, 2012 at 02:16:12PM +0200, Richard Guenther wrote:
>> Or figure out if or why not the vectorizer does catch this (of course we do
>> not enable that with -O2 which we eventually should in a very conservative
>> mode).
>
> It mi
On Sat, Aug 18, 2012 at 9:01 AM, Tobias Burnus wrote:
> Steven Bosscher wrote:
>>
>> This reduces peak memory usage for the small test case of PR54146
>> Bootstrapped&tested on x86_64-unknown-linux-gnu. OK for trunk?
>
>
> I think it's your patch which
On Sat, Aug 18, 2012 at 12:21 PM, Tobias Burnus wrote:
> I filled a small bug report at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54313
Yup, thanks.
* dse.c (dse_step7): Don't free kill_on_calls bitmap, it is
freed when its obstack is release.
Index: dse.c
==
On Sat, Aug 18, 2012 at 12:39 PM, Richard Guenther
wrote:
> On Sat, Aug 18, 2012 at 12:28 PM, Steven Bosscher
> wrote:
>> On Sat, Aug 18, 2012 at 12:21 PM, Tobias Burnus wrote:
>>> I filled a small bug report at
>>> http://gcc.gnu.org/bugzilla/show_bug.
On Thu, Aug 16, 2012 at 12:06 PM, Richard Guenther
wrote:
> On Thu, Aug 16, 2012 at 1:11 AM, Steven Bosscher
> wrote:
>> On Mon, Aug 6, 2012 at 1:27 PM, Paolo Bonzini wrote:
>>>> 2. sparseset has the same problem of memory clearing (for valgrind,
>>>> see sp
On Sun, Aug 19, 2012 at 8:31 PM, Dimitrios Apostolou wrote:
> Hello,
>
> 2012-08-19 Dimitrios Apostolou
>
> * gcc/cselib.c (cselib_init): Make allocation pools larger since
> they are too hot and show to expand often on the profiler.
> * gcc/df-problems.c (df_chain_alloc
On Mon, Aug 20, 2012 at 4:54 PM, Dimitrios Apostolou wrote:
> In the process I realised that obstacks weren't exactly suitable (thanks
> matz for helping on IRC),
Right, alloc-pool would be a better choice here.
Ciao!
Steven
On Mon, Aug 20, 2012 at 11:48 AM, Jan Hubicka wrote:
>> The summary merging in coverage.c confuses me a bit as it seems to be
>> handling the case when there are multiple program summaries in a
>> single gcda file. When would this happen? It looks like the merge
>> handling in libgcov should alway
On Mon, Aug 20, 2012 at 7:44 PM, Teresa Johnson wrote:
> But
> the code in coverage.c is dealing with a single gcda file containing
> multiple program summaries. Is there code somewhere that will cause
> this to happen?
Not that I know of, no.
(There are enhancement requests for this, see e.g. PR
Hello,
Two more bitmap obstacks, this time in tree-ssa-coalesce.c.
The advantage isn't so much in having the bitmaps on the non-default
obstack, but more in that the bitmaps can be free'ed all at once by
simply releasing the obstack.
Bootstrapped&tested on x86_64-unknown-linux-gnu. OK for trunk?
On Tue, Aug 21, 2012 at 10:33 PM, Jakub Jelinek wrote:
> Hi!
>
> The recent change in find_assert_locations from XCNEWVEC to XNEWVEC
> caused a valgrind warning, because bb_rpo[ENTRY_BLOCK] used to
> be accessed, but was never initialized.
Sorry for this breakage. I looked at each of the changes
Hello,
This both speeds up and improves RTL alias analysis by propagating the
alias chains information in a visit in topological order of the CFG.
Perhaps unsurprisingly, this is motivated again by PR
middle-end/54146, where I noticed that the loop in init_alias_analysis
terminated because the it
On Wed, Aug 22, 2012 at 3:44 PM, Jakub Jelinek wrote:
> To me the patch looks way too long, changing too many things, to be suitable
> for the release branch.
Most of the changes are only to allocate bitmaps on dedicated
obstacks. It makes the patch long, but the changes are not really
significan
On Wed, Aug 22, 2012 at 3:01 PM, Richard Guenther wrote:
>
> While we should already be in loop-closed SSA form for virtual
> operands most of the time (because we have a virtual use at
> the return statement) and loop-closed SSA form for virtuals
> is cheap (we only have a single virtual operand
Hello Bill,
This patch plugs a leak in rs6000.c:rs6000_density_test(). You have to
free the array that get_loop_body returns. Noticed while going over
all uses of get_loop_body (it's a common mistake to leak the return
array).
Patch is completely untested because I don't know when/how this
functi
On Thu, Aug 23, 2012 at 9:35 AM, Richard Guenther wrote:
> + The same applies to virtual operands which are also rewritten into
> + loop closed SSA form. Note that virtual operands are always live
> + until function exit.
Ouch!
What does this do to the memory foot print and com
... because they're not partitioned anyway, so they just confuse the dumps:
Will bootstrap&test, and commit if nothing strange shows up.
Ciao!
Steven
* tree-ssa-live.c (dump_var_map): Do not dump the partition
map of virtual operands.
Index: tree-ssa-live.c
=
On Wed, Aug 22, 2012 at 8:49 AM, Zhenqiang Chen wrote:
>> The patch is to enable bbro for -Os. When optimizing for size, it
>> * avoid duplicating block.
>> * keep its original order if there is no chance to fall through.
>> * ignore edge frequency and probability.
>> * handle predecessor first if
On Fri, Aug 24, 2012 at 6:33 PM, Thomas Quinot wrote:
> * common.opt (-fada-spec-parent): Define new command line switch.
Why here instead of in c-family/c.opt?
Ciao!
Steven
Hello,
This patch restores the old invariant that every GIMPLE switch has a
default case. This invariant is only broken by the SJLJ exception
dispatch code, and it's resulted in some code accepting a switch
without a default while others still assume there is _always_ a
default case. The patch enf
Hello,
With my patch to visit insns in topological order in
init_alias_analysis, an issue in postreload-cse got exposed: Blocks
may become unreachable between calls of reload_cse_regs_1 but no CFG
cleanups are scheduled between them, resulting in an ICE in
pre_and_rev_post_order_compute at an asse
On Mon, Aug 27, 2012 at 10:32 PM, Eric Botcazou wrote:
>> This patch fixes the problem by deleting unreachable basic blocks if
>> edges were purged during a reload-cse transformation on an insn. I
>> didn't add a test case because reliably triggering problems this late
>> in the pass pipeline is s
Will commit as obvious.
* cfg.c (dump_bb_info): Print a newline if there were no edges to dump.
Index: cfg.c
===
--- cfg.c (revision 190785)
+++ cfg.c (working copy)
@@ -764,6 +764,8 @@ dump_bb_info (FILE *outf, basic_blo
On Fri, Aug 31, 2012 at 6:51 PM, Richard Henderson wrote:
> Fixed as follows. This seems to be the only entry point in alias.c that
> didn't take ALIAS_SET_MEMORY_BARRIER into account. Getting the above into a
> test case is tricky, and I havn't figured out how to match it.
>
> Full testing st
> Full testing still underway, but I expect it to pass.
Can you also update the comment before the function, please? It now reads:
/* Read dependence: X is read after read in MEM takes place. There can
only be a dependence here if both reads are volatile. */
But that's no longer true after
Ping!
On Sat, Aug 25, 2012 at 1:14 AM, Steven Bosscher wrote:
> Hello,
>
> This patch restores the old invariant that every GIMPLE switch has a
> default case. This invariant is only broken by the SJLJ exception
> dispatch code, and it's resulted in some code accepting
Hello,
r190783 breaks bootstrap on powerpc64-unknown-linux-gnu. The problem
is caused by a regexp that used to check for space|tab before the
patch but now only looks for tab. The attached patch fixes this
problem for me, but I'm not sure why (I haven't tried to look into the
details of the proble
On Sun, Sep 2, 2012 at 1:22 PM, Uros Bizjak wrote:
> Hello!
>
> Attached patch prevents compute_bb_for_insn to calculate BB for
> barrier RTXes. This is in fact the same approach all other
> *_bb_for_insn use.
>
> The patch is bordering on obvious.
It is anything _but_ obvious. The code looks lik
On Sun, Sep 2, 2012 at 1:46 PM, Uros Bizjak wrote:
> On Sun, Sep 2, 2012 at 1:38 PM, Steven Bosscher wrote:
>> On Sun, Sep 2, 2012 at 1:22 PM, Uros Bizjak wrote:
>>> Hello!
>>>
>>> Attached patch prevents compute_bb_for_insn to calculate BB for
>>
On Tue, Sep 4, 2012 at 3:19 PM, Richard Guenther wrote:
>
> Currently computa_avail consumes an unreasonable amount of memory
> in the FRE case for PR46590. The following patch makes some
> obvious adjustments but does not cure the underlying issue.
I don't think there's any way to cure the unde
On Tue, Sep 4, 2012 at 11:07 PM, Diego Novillo wrote:
> Fix bootstrap failure with clang++.
>
> This patch fixes a bootstrap failure when using clang as the host
> compiler. Default arguments for class template member functions
> should be added in the declaration, not the definition.
>
> From Ja
On Tue, Sep 4, 2012 at 6:43 PM, Andi Kleen wrote:
> +/* Compact representation of a index <-> resolution pair. Unpacked to an
> + vector later. */
> +struct res_pair
> +{
> + ld_plugin_symbol_resolution_t res;
> + unsigned index;
> +};
> +typedef struct res_pair res_pair;
> +
> +DEF_VEC_P(res_
On Wed, Sep 5, 2012 at 10:46 AM, Matthew Gretton-Dann
wrote:
>> Please, no inlining. Think of stack back-traces and their use
>> when debugging.
>
> I would argue [without sufficient knowledge of how easy this would
> actually be to do in a real compiler :-)] that this is a debugger
> problem and
On Wed, Sep 5, 2012 at 1:25 PM, Matthew Gretton-Dann wrote:
> + /* If the two blocks are in different partitions we do not want to mark
> + this as a fallthru edge. */
> + if (BB_PARTITION (b) != BB_PARTITION (c))
> +return;
> +
I think you should look for a REG_CROSSING_JUMP note on
On Wed, Sep 5, 2012 at 1:42 PM, Matthew Gretton-Dann wrote:
> Whilst this fix works for this particular case I am not sure it is the
> best fix for the general issue, and so if others have a better idea how
> to fix this I would be very happy.
postreload-gcse.c is broken in "interesting" ways. Loo
On Wed, Sep 5, 2012 at 3:18 PM, Matthew Gretton-Dann
wrote:
> On 5 September 2012 13:45, Richard Earnshaw wrote:
>> On 05/09/12 13:02, Steven Bosscher wrote:
>>> On Wed, Sep 5, 2012 at 1:42 PM, Matthew Gretton-Dann wrote:
>>>> Whilst this fix works for this parti
Hello,
Just some cleanups I did while working on something bigger.
OK for trunk?
Ciao!
Steven
* graphite.c (print_global_statistics): Use EDGE_COUNT instead
of VEC_length.
(print_graphite_scop_statistics): Likewise.
* graphite-scop-detection.c (get_bb_type): Use
Hi,
bitmap.c:bitmap_last_set_bit() is not used by any code in the current
GCC trunk, but I'm using it and I noticed it returns an incorrect
result. This patch rewrites most of the function to return the correct
result.
Not sure how to test this other than to say that my code, that uses
this funct
601 - 700 of 1067 matches
Mail list logo
