[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 --- Comment #28 from dnovillo at google dot com 2013-05-08 13:23:22 UTC --- On 2013-05-08 06:05 , Richard Biener wrote: > On Tue, 7 May 2013, Diego Novillo wrote: > >> On 2013-05-07 13:06 , roland at gnu dot org wrote: >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 >>> >>> --- Comment #25 from roland at gnu dot org 2013-05-07 17:06:56 UTC --- >>> I have been using a straightforward revert of r190487 to build on mingw with >>> --disable-nls. It works. >>> >> >> Thanks. Then I just need to confirm that this doesn't re-introduce >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281. Richi, could you check >> that? Do you still have access to 4.1 host compilers? > I've verified that reverting r190487 on the 4.8 branch does not > re-introduce the issue on the originally affected host system. > > Richard. Thanks, folks. I've applied the patch to trunk and gcc-4_8-branch. Diego.
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 --- Comment #26 from dnovillo at google dot com 2013-05-07 17:10:07 UTC --- On 2013-05-07 13:06 , roland at gnu dot org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 > > --- Comment #25 from roland at gnu dot org 2013-05-07 17:06:56 UTC --- > I have been using a straightforward revert of r190487 to build on mingw with > --disable-nls. It works. > Thanks. Then I just need to confirm that this doesn't re-introduce http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281. Richi, could you check that? Do you still have access to 4.1 host compilers?
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 --- Comment #21 from dnovillo at google dot com 2013-04-29 16:46:27 UTC --- On 2013-04-29 11:25 , jakub at gcc dot gnu.org wrote: > Any progress with this? We'd like to do 4.8.1-rc1 in mid-May, would be nice > to > have this resolved till then. > None at all, sorry. I will try to work on this after I get back (early next week). Diego.
[Bug rtl-optimization/56348] internal compiler error in assign_by_spills with -m32 -fPIC -msse2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56348 --- Comment #3 from dnovillo at google dot com 2013-02-15 19:19:22 UTC --- Thanks for the quick fix, Vlad! Diego.
[Bug c++/55742] __attribute__ in class function declaration cause "prototype does not match" errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #4 from dnovillo at google dot com 2012-12-20 18:23:55 UTC --- On Thu, Dec 20, 2012 at 1:21 PM, tmsriram at google dot com wrote: > However, with function multiversioning, this will become a problem as > multiversioning does not treat two decls with different target attributes > as > identical. Since we are enabling multiversioning by default, atleast in > C++ > front-end for now, IMO, it is better to insist that the definition and > declaration contain identical target attributes. Unfortunately, we cannot do that. A lot of existing code relies on this attribute merging. The cleanest approach here is probably to add an additional 'mv' attribute to explicitly enable multiversioning. Breaking the existing semantics is going to break a lot of code. Diego.
[Bug regression/55486] FAIL: gcc.dg/sms-7.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55486 --- Comment #3 from dnovillo at google dot com 2012-11-30 15:53:02 UTC --- On Fri, Nov 30, 2012 at 10:38 AM, kyrylo.tkachov at arm dot com wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55486 > > --- Comment #2 from Kyrill Tkachov 2012-11-30 > 15:38:33 UTC --- > (In reply to comment #1) >> > Target: arm-none-eabi >> > >> > gcc.dg/sms-7.c:17:1: internal compiler error: in schedule_reg_moves, at >> > modulo-sched.c:725 >> >> Can you show me the backtrace dump? >> >> >> Thanks. Diego. > > Hi Diego, > > As of today, the ICE has gone. The compilation test passes. > But the execution test fails on qemu: > FAIL: gcc.dg/sms-7.c execution test The compilation failure was likely fixed by rev 193667. 2012-11-20 Diego Novillo PR middle-end/55398 * vec.h (class vec_prefix): Make every field public. Rename field alloc_ to alloc_PRIVATE_. Rename field num_ to num_PRIVATE_. Update all users. (class vec): Make every field public. Rename field pfx_ to pfx_PRIVATE_. Rename field data_ to data_PRIVATE_. Update all users. (class vec): Make every field public. Rename field vec_ to vec_PRIVATE_. Update all users. > Should this be a separate issue then? I think so. Do you know at what rev was this test executing successfully? A binary search between the two revs may not help since you'll run into the ICE. But I would start diffing dump files between the working and the broken revision. Diego.
[Bug regression/55486] FAIL: gcc.dg/sms-7.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55486 --- Comment #1 from dnovillo at google dot com 2012-11-30 15:14:10 UTC --- On Tue, Nov 27, 2012 at 6:25 AM, kyrylo.tkachov at arm dot com wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55486 > > Bug #: 55486 >Summary: FAIL: gcc.dg/sms-7.c (internal compiler error) > Classification: Unclassified >Product: gcc >Version: 4.8.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: regression > AssignedTo: unassig...@gcc.gnu.org > ReportedBy: kyrylo.tkac...@arm.com > CC: dnovi...@google.com > Target: arm-none-eabi > > > FAIL: gcc.dg/sms-7.c (internal compiler error) > FAIL: gcc.dg/sms-7.c (test for excess errors) > > Target: arm-none-eabi > > gcc.dg/sms-7.c:17:1: internal compiler error: in schedule_reg_moves, at > modulo-sched.c:725 Can you show me the backtrace dump? Thanks. Diego.
[Bug bootstrap/55384] [4.8 Regresson] VEC merge AIX bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55384 --- Comment #5 from dnovillo at google dot com 2012-11-19 01:05:32 UTC --- On Sun, Nov 18, 2012 at 7:21 PM, dje at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55384 > > --- Comment #4 from David Edelsohn 2012-11-19 > 00:21:59 UTC --- > AIX /usr/include/stdlib.h includes > > #define vec_free free Sigh. Silly AIX. > And vec.h defines two functions named vec_free, which get renamed, causing > ambiguity in the splay_tree_new calls. > > Should vec.h #undef vec_free? Somewhere else? I suppose it will have to how can I recognize AIX inside vec.h? Diego.
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 --- Comment #3 from dnovillo at google dot com 2012-10-26 12:34:53 UTC --- On Fri, Oct 26, 2012 at 8:05 AM, rguenther at suse dot de wrote: > Fact is that all this stuff happens because gmp.h is not included > from system.h ... I broke Ada when I tried it. I don't remember the details, but it seemed tedious to fix. Diego.
[Bug bootstrap/54484] r190927 breaks bootstrap with clang compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54484 --- Comment #8 from dnovillo at google dot com 2012-09-05 16:38:21 UTC --- On 2012-09-05 12:11 , glisse at gcc dot gnu.org wrote: > I meant the one in this PR's description. The second overload of lower_bound > takes an argument lessthan_ but uses lessthan (no underscore). Thanks. Good catch. I just committed a fix for it. > I assume it is never instantiated? Right. Otherwise, we'd get an error while building stage2. Diego.
[Bug bootstrap/54484] r190927 breaks bootstrap with clang compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54484 --- Comment #5 from dnovillo at google dot com 2012-09-05 11:48:38 UTC --- On Wed, Sep 5, 2012 at 2:12 AM, glisse at gcc dot gnu.org wrote: > did you also take a look at the warning about lessthan_ in the clang messages? No. Clang's output was very noisy. I did not look at any warnings, just waited for the error that was preventing the build. Diego.
[Bug rtl-optimization/54343] RTL postreload leaks DF memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54343 --- Comment #5 from dnovillo at google dot com 2012-08-22 12:43:02 UTC --- On 2012-08-22 05:32 , rguenth at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54343 > > --- Comment #4 from Richard Guenther 2012-08-22 > 09:32:13 UTC --- > (In reply to comment #3) >> HJ's fix for PR 54332 will probably fix this one, too. Could you re-test? >> >> Thanks. > > Doesn't fix it. OK, then it wasn't related. Do you know if this started happening with rev 190402? Diego.
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #25 from dnovillo at google dot com 2012-08-21 20:49:16 UTC --- On 2012-08-21 15:53 , hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 > > --- Comment #24 from H.J. Lu 2012-08-21 19:53:14 > UTC --- > (In reply to comment #23) >> >> The problem with this is that you are switching a stack vec into a heap >> vec. This may not always be what the caller wanted. > > My patch just restores the old behavior. You are right. This was always the case. I added the extra check to guard against inadvertent *initial* heap allocations for stack vectors. But now that I see the old code, this was always the case. The subsequent stack operations after the first round around the loop will move the stacks into the heap. The patch is OK with a ChangeLog and bootstrap testing. Thanks! Diego.
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
--- Comment #23 from dnovillo at google dot com
2012-08-21 19:50:12 UTC ---
On 2012-08-21 15:27 , hjl.tools at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
>
> --- Comment #22 from H.J. Lu 2012-08-21 19:27:50
> UTC ---
> This seems to work:
>
> diff --git a/gcc/df-scan.c b/gcc/df-scan.c
> index 35100d1..39f444f 100644
> --- a/gcc/df-scan.c
> +++ b/gcc/df-scan.c
> @@ -4392,6 +4392,7 @@ df_bb_verify (basic_block bb)
> if (!INSN_P (insn))
> continue;
> df_insn_refs_verify (&collection_rec, bb, insn, true);
> + df_free_collection_rec (&collection_rec);
> }
>
> /* Do the artificial defs and uses. */
> diff --git a/gcc/vec.h b/gcc/vec.h
> index cc7e819..3a298ff 100644
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -1031,21 +1031,9 @@ vec_reserve (vec_t *vec_, int reserve MEM_STAT_DECL)
> sizeof (T), false
> PASS_MEM_STAT);
> else
> -{
> - /* Only allow stack vectors when re-growing them. The initial
> - allocation of stack vectors must be done with the
> - VEC_stack_alloc macro, because it uses alloca() for the
> - allocation. */
> - if (vec_ == NULL)
> -{
> - fprintf (stderr, "Stack vectors must be initially allocated "
> - "with VEC_stack_alloc.\n");
> - gcc_unreachable ();
> -}
> - return (vec_t *) vec_stack_o_reserve (vec_, reserve,
> - offsetof (vec_t, vec),
> - sizeof (T) PASS_MEM_STAT);
> -}
> +return (vec_t *) vec_stack_o_reserve (vec_, reserve,
> + offsetof (vec_t, vec),
> + sizeof (T) PASS_MEM_STAT);
> }
>
The problem with this is that you are switching a stack vec into a heap
vec. This may not always be what the caller wanted.
The other alternative is to truncate the vectors after the call to
df_insn_refs_verify().
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #20 from dnovillo at google dot com 2012-08-21 19:07:33 UTC --- On 2012-08-21 14:54 , hjl.tools at gmail dot com wrote: > With --enable-gather-detailed-mem-stats, I got > > Alloc-pool Kind Elt size Pools Allocated (elts)Peak > (elts)Leak (elts) > > -df_scan ref base 64 18 24808192(387628) 11869056( > 185454) 0( 0) > -df_scan ref artificial 72 18 15168528(210674)2044944( > 28402) 0( 0) > +df_scan ref base 64 18 513091264( 8017051) 500077440( > 7813710) 0( 0) > +df_scan ref artificial 72 18 599905368( 8332019)2044944( > 28402) 0( 0) > elt_loc_list 32 277982112(249441)2399488( > 74984) 0( 0) > -df_scan ref regular72 18 71483184(992822) 45955584( > 638272) 0( 0) > +df_scan ref regular72 18 2091195360( 29044380) 2065579776( > 28688608) 0( 0) > df_scan insn 56 187681016(137161)3340848( > 59658) 0( 0) > > -Total 15775 253131240 > +Total 16067 3345899232 > That agrees with what I found, thanks. I've added a link to the discussion about the df verifier. The vectors need to be cleared, but I can't just free the vectors: Stack vectors must be initially allocated with VEC_stack_alloc. gcc/df-scan.c: In function 'unsigned int df_count_refs(bool, bool, bool)': gcc/df-scan.c:1507:1: internal compiler error: in vec_reserve, at vec.h: }
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #18 from dnovillo at google dot com 2012-08-21 18:31:51 UTC --- OK, I think this is the hunk that's causing grief: diff --git a/gcc/df-scan.c b/gcc/df-scan.c index 39f444f..35100d1 100644 --- a/gcc/df-scan.c +++ b/gcc/df-scan.c @@ -4392,7 +4392,6 @@ df_bb_verify (basic_block bb) if (!INSN_P (insn)) continue; df_insn_refs_verify (&collection_rec, bb, insn, true); - df_free_collection_rec (&collection_rec); } /* Do the artificial defs and uses. */ I remember that I ran into this during the VEC conversion (http://gcc.gnu.org/ml/gcc/2012-05/msg00271.html) and after some discussion I ended up convincing myself that taking it out was harmless. Clearly, I was wrong. I've hooked gdb to the running f951 and it's stuck in df_bb_verify(). Odd that this has not triggered anywhere else.
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #17 from dnovillo at google dot com 2012-08-21 18:19:10 UTC --- On 2012-08-21 14:08 , hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 > > --- Comment #16 from H.J. Lu 2012-08-21 18:08:49 > UTC --- > There are: > > opts.c:typedef char *char_p; /* For DEF_VEC_P. */ > opts.c:DEF_VEC_P(char_p); > opts.c:DEF_VEC_ALLOC_P(char_p,heap); > opts-global.c:typedef const char *const_char_p; /* For DEF_VEC_P. */ > opts-global.c:DEF_VEC_P(const_char_p); > opts-global.c:DEF_VEC_ALLOC_P(const_char_p,heap); > > Will they cause problems if other files define similar types? > They shouldn't. DEF_VEC_* expands to a NOP now. The allocation strategy is only needed during the actual allocation call. So, in the case of opts.c, that would be in add_comma_separated_to_vector() (the call to VEC_safe_push). Those two vectors are only used for -finstrument-options..., though. So that does not seem related. The call to postpone_unknown_option_warning in opts-global.c seems also unrelated. It's only used when processing unknown options. That vector is popped when the unknown options are freed, so that can't be it either.
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #10 from dnovillo at google dot com 2012-08-21 16:44:10 UTC --- On Tue, Aug 21, 2012 at 12:20 PM, hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 > > --- Comment #9 from H.J. Lu 2012-08-21 16:20:37 > UTC --- > Revision 188059 is bad: > > f951: out of memory allocating 36872 bytes after a total of 583266304 bytes Thanks. Does rev 188129 show the same thing? The next revisions to try are: 188040 (TREE_CHECK macros) 187954 (merge from trunk) 187836 (initial VEC conversion) 187735 (merge from trunk) I now have access to SPEC2006, I'll try a build.
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #8 from dnovillo at google dot com 2012-08-21 14:06:34 UTC --- On 2012-08-21 09:58 , hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 > > --- Comment #7 from H.J. Lu 2012-08-21 13:58:05 > UTC --- > (In reply to comment #6) >> >> If it's related to the hash table, then comparing rev 188059 vs rev >> 188129 may show the regression. >> > > Neither rev 188059 nor rev 188129 will build: > > ../../../../gcc/gcc/graphite-sese-to-poly.c: In function \u2018void > build_sese_conditions_before(dom_walk_data*, basic_block)\u2019: > ../../../../gcc/gcc/graphite-sese-to-poly.c:1357:2: error: call of overloaded > \u2018VEC_safe_push_1(vec_t**, NULL, const char [44], > int, > const char [29])\u2019 is ambiguous > ../../../../gcc/gcc/graphite-sese-to-poly.c:1357:2: note: candidates are: > In file included from ../../../../gcc/gcc/basic-block.h:25:0, > from ../../../../gcc/gcc/tree-flow.h:27, > from ../../../../gcc/gcc/graphite-sese-to-poly.c:24: > ../../../../gcc/gcc/vec.h:674:1: note: T& VEC_safe_push_1(vec_t**, T, const > char*, unsigned int, const char*) [with T = gimple_statement_d*; > vec_allocation_t A = (vec_allocation_t)0u] > ../../../../gcc/gcc/vec.h:682:1: note: T* VEC_safe_push_1(vec_t**, const > T*, > const char*, unsigned int, const char*) [with T = gimple_statement_d*; > vec_allocation_t A = (vec_allocation_t)0u] > make[2]: *** [graphite-sese-to-poly.o] Error 1 >2692,40 > 99% > Huh, odd. Can you try this patchlet on top of those revs? It builds for me with this applied: diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c index cdabd73..5712e58 100644 --- a/gcc/graphite-sese-to-poly.c +++ b/gcc/graphite-sese-to-poly.c @@ -1354,7 +1354,7 @@ build_sese_conditions_before (struct dom_walk_data *dw_data, if (e->flags & EDGE_TRUE_VALUE) VEC_safe_push (gimple, heap, *cases, stmt); else - VEC_safe_push (gimple, heap, *cases, NULL); + VEC_safe_push (gimple, heap, *cases, (gimple) NULL); } gbb = gbb_from_bb (bb);
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 --- Comment #6 from dnovillo at google dot com 2012-08-21 13:38:24 UTC --- On 2012-08-20 22:59 , hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332 > > --- Comment #4 from H.J. Lu 2012-08-21 02:59:15 > UTC --- > It was introduced between revision 189101 and revision 189664 > on cxx-conversion branch. Unfortunately, since branch was broken > between those 2 revisions, I can't bisect further. > There was no rev 189101 in cxx-conversion. That is a trunk revision. In that range of revisions, there are only merges from trunk until rev 188129, which introduces the new hash table. Prior to that, we have rev 188059, which makes cosmetic changes to configure.ac. If it's related to the hash table, then comparing rev 188059 vs rev 188129 may show the regression. Diego.
[Bug c++/51554] ICE in cp/semantics.c:cxx_eval_indirect_ref with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51554 --- Comment #2 from dnovillo at google dot com 2011-12-14 22:32:33 UTC --- Wow, that was quick, thanks! Diego. On Wed, Dec 14, 2011 at 17:26, jason at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51554 > > --- Comment #1 from Jason Merrill 2011-12-14 > 22:26:27 UTC --- > Author: jason > Date: Wed Dec 14 22:26:24 2011 > New Revision: 182346 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182346 > Log: > PR c++/51554 > * semantics.c (cxx_eval_indirect_ref): Fix sanity check. > > Added: > trunk/gcc/testsuite/g++.dg/init/constant1.C > Modified: > trunk/gcc/cp/ChangeLog > trunk/gcc/cp/semantics.c > trunk/gcc/testsuite/ChangeLog > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug.
[Bug c++/51382] Incorrect diagnostic "cannot appear in a constant-expression"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51382 --- Comment #2 from dnovillo at google dot com 2011-12-01 22:39:02 UTC --- On Thu, Dec 1, 2011 at 17:19, paolo.carlini at oracle dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51382 > > --- Comment #1 from Paolo Carlini > 2011-12-01 22:19:10 UTC --- > PR51319 (or PRs referenced therein) ? Sorry?
[Bug bootstrap/51346] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51346 --- Comment #7 from dnovillo at google dot com 2011-12-01 18:20:37 UTC --- On Thu, Dec 1, 2011 at 13:12, howarth at nitro dot med.uc.edu wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51346 > > Jack Howarth changed: > > What |Removed |Added > > CC| |howarth at nitro dot > | |med.uc.edu > > --- Comment #6 from Jack Howarth 2011-12-01 > 18:12:35 UTC --- > On x86_64-apple-darwin11, this failure occurs for a simple lto-bootstrap and > doesn't require bootstrap-profiled to trigger the problem. I'm about to commit a patch that should fix this bug. Diego.
[Bug lto/50165] [4.7 Regression] Huge build time regression (Firefox lto build)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165 --- Comment #9 from dnovillo at google dot com 2011-08-26 12:21:33 UTC --- I will be with limited e-mail access until 7-Sep-2011. I will read your message when I get back. Diego.
[Bug c++/40975] [4.3/4.4/4.5/4.6 Regression] ICE in copy_tree_r on array new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40975 --- Comment #8 from dnovillo at google dot com 2011-04-28 17:37:29 UTC --- On Thu, Apr 28, 2011 at 13:01, jason at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40975 > > Jason Merrill changed: > > What |Removed |Added > > CC| |dnovillo at gcc dot gnu.org > > --- Comment #7 from Jason Merrill 2011-04-28 > 15:57:06 UTC --- > This was broken by the tree-ssa merge, r81764, which introduced STATEMENT_LIST > and caused copy_tree_r to abort on it. Diego, do you happen to remember the > rationale for that? Why can't we copy a STATEMENT_LIST in a > statement-expression? Oh, boy. Sorry. I do not remember why we added that assertion. It may have been to avoid recursing twice, since copy_tree_r is typically called to copy individual statements in a list. So, we never expected to find STATEMENT_LISTs inside a single statement. This may be largely unnecessary now. Diego. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug. >
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #19 from dnovillo at google dot com 2009-02-25 16:12 --- Subject: Re: Loop IM and other optimizations harmful for -fopenmp On Wed, Feb 25, 2009 at 11:06, davids at webmaster dot com wrote: > > > --- Comment #18 from davids at webmaster dot com  2009-02-25 16:06 > --- > This is a real bug. There is simply no way to write correct threaded code if > the compiler is free to read a variable and write it back when the code didn't > specifically tell it to. Yes. Unless we build an actual concurrent data flow and adapt the optimizers for these programs, we will never get it right. The best approach in these cases is to tell the optimizers to back off completely. After all the code has completely different semantics from what they are ready to handle. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug driver/39276] [lto] - Testsuite gcc.log shows many "getconf: Invalid argument (_NPROCESSORS_ONLN)"
--- Comment #4 from dnovillo at google dot com 2009-02-23 17:33 --- Subject: Re: [lto] - Testsuite gcc.log shows many "getconf: Invalid argument (_NPROCESSORS_ONLN)" On Mon, Feb 23, 2009 at 12:29, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-23 17:29 > --- > I don't think ltrans-driver should be a shell script anyways because on > windows > you will most likely not have /bin/sh installed. Yes, ltrans-driver is a quick hack. It probably only works reliably on some variants of Linux. It's a small script, so it should be easy to fix. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39276
[Bug tree-optimization/39203] LTO and -fwhole-program do not play along well
--- Comment #13 from dnovillo at google dot com 2009-02-18 12:26 --- Subject: Re: LTO and -fwhole-program do not play along well On Tue, Feb 17, 2009 at 20:42, hubicka at ucw dot cz wrote: > > > --- Comment #12 from hubicka at ucw dot cz 2009-02-18 01:42 --- > Subject: Re: LTO and -fwhole-program do not play along well > >> I believe we should be set already. During LTO read, we execute >> ipa_passes, which runs all_small_ipa_passes. So, >> pass_ipa_function_and_variable_visibility is run both while writing >> the IL and right after we read it in. >> >> Is that what you were referring to? > > Well, you need to localize stuff at WHOPR stage, so small IPA passes are > unlikely going to be executable there except for those not needing > function bodies (like the visibility pass, but unlike inlining and other > stuff included). Are those still skipped via the lto flag gate? Yes, with whopr, the only time we can ever operate in whole-program mode is when we run the analysis stage (-fwpa). The other two stages cannot operate in whole-program mode as they only deal with a partial graph. For -flto, however, we can enable whole-program mode as we are dealing with the whole callgraph at once. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39203
[Bug tree-optimization/39203] LTO and -fwhole-program do not play along well
--- Comment #9 from dnovillo at google dot com 2009-02-17 18:51 --- Subject: Re: LTO and -fwhole-program do not play along well On Tue, Feb 17, 2009 at 13:34, hubicka at ucw dot cz wrote: > Essentially yes, but since we are restarting the pass queue from later > time, won't we miss the visibility pass at linktime? > This is why I think we need two passes (one very early and one scheduled > after LTO read) I believe we should be set already. During LTO read, we execute ipa_passes, which runs all_small_ipa_passes. So, pass_ipa_function_and_variable_visibility is run both while writing the IL and right after we read it in. Is that what you were referring to? Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39203
[Bug tree-optimization/39203] LTO and -fwhole-program do not play along well
--- Comment #7 from dnovillo at google dot com 2009-02-17 18:05 --- Subject: Re: LTO and -fwhole-program do not play along well On Tue, Feb 17, 2009 at 13:01, hubicka at ucw dot cz wrote: > This is intended behaviour. Agreed. > -fwhole-program essentially hides everything except for main and > functions/variables explicitly marked via attribute, so this is > exepcted. You need to use --combine and or -lto to compile programs > consisting of multiple compilation units with -fwhole-program. Yes. As I just replied upthread, I think we could just turn off flag_whole_program when we know we are just generating IL out of the front ends. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39203
[Bug tree-optimization/39203] LTO and -fwhole-program do not play along well
--- Comment #6 from dnovillo at google dot com 2009-02-17 18:04 --- Subject: Re: LTO and -fwhole-program do not play along well On Tue, Feb 17, 2009 at 13:02, rguenther at suse dot de wrote: > Well, of course. Just the idea that -flto can be used easily without > too much makefile adjustment doesn't play well here. If I specify > -fwhole-program only at link time, will it still do the > necessary privatization? Yes, it should. But I think we could provide the added benefit of turning off -fwhole-program when generating IL from the front ends. It's just a single line change. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39203
[Bug tree-optimization/39203] LTO and -fwhole-program do not play along well
--- Comment #3 from dnovillo at google dot com 2009-02-17 17:55 --- Subject: Re: LTO and -fwhole-program do not play along well On Tue, Feb 17, 2009 at 12:43, hubicka at ucw dot cz wrote: > > > --- Comment #2 from hubicka at ucw dot cz 2009-02-17 17:43 --- > Subject: Re: LTO and -fwhole-program do not play along well > > Hi, > functions are brought local in function_and_variable_visibility that > needs to be scheduled after LTO is read in. > The pas computes externaly_visible flags that should be up-to-date for > early IPA passes before LTO is written out, so I guess we need early > function_and_vairable_visibility pass and late one where the first one > is not bringing functions local at -fwhole-program -lto OK, but I think there is a bigger issue here. Even if -flto is *not* used, we get link errors. Just by compiling each file with -fwhole-program is enough to reproduce the failure: $ gcc -fwhole-program -c f1.c $ gcc -fwhole-program -c f2.c $ gcc -fwhole-program -o f f1.o f2.o This is just a natural side-effect of using -fwhole-program. It was not intended to be used like this. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39203
[Bug middle-end/39009] [LTO] ICE: in make_decl_rtl, at varasm.c:1288
--- Comment #1 from dnovillo at google dot com 2009-01-28 20:36 --- Subject: Re: New: [LTO] ICE: in make_decl_rtl, at varasm.c:1288 Thanks for the bug reports. At this stage, I'm not sure if it's useful to file a bug report for every test in the GCC testsuite. These failures are highly visible already and there are about 1,200 of them, so having a separate bug report for each of them may be excessive. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39009
[Bug bootstrap/38992] [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64
--- Comment #7 from dnovillo at google dot com 2009-01-28 18:56 --- Subject: Re: [LTO] Bootstrap failed on RHEL5/ia32 and RHEL5/ia64 On Wed, Jan 28, 2009 at 13:49, hjl dot tools at gmail dot com wrote: > I bootstrapped it on RHEL5/ia32, RHEL5/ia64 and Fedora 10/x86-64. > There are many failures in testsuite. I don't believe they are > caused by my patch. Fixed. Thanks. The testsuite is rather messy at the moment, so the best way to detect new failures is to compare against an unpatched tree. I post daily builds on x86 to gcc-testresults, so you could use those. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38992
[Bug tree-optimization/38458] copy-propagation doesn't handle cycles
--- Comment #1 from dnovillo at google dot com 2008-12-09 20:22 ---
Subject: Re: New: copy-propagation doesn't
handle cycles
On Tue, Dec 9, 2008 at 14:53, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>{
> - phi_val.value = arg;
> + phi_val.value = arg_val->value;
> continue;
>}
This looks OK.
> - rhs_val = get_copy_of_val (rhs);
> + rhs_val = get_last_copy_of (rhs);
We don't want to propagate using get_last_copy_of here. The reason
now escapes me, but it should be documented in the code. It was
related to phi-cycles, but it's been a long time.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38458
[Bug tree-optimization/33237] [4.3/4.4 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #17 from dnovillo at google dot com 2008-12-08 15:03 --- Subject: Re: [4.3/4.4 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile. On Sun, Dec 7, 2008 at 06:55, steven at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #15 from steven at gcc dot gnu dot org 2008-12-07 11:55 > --- > Diego, in comment #7 you said you will work on this... > So? Have you worked on this? Not at all. Sorry. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/32921] [4.3/4.4 Regression] Revision 126326 causes 12% slowdown
--- Comment #50 from dnovillo at google dot com 2008-05-02 12:32 --- Subject: Re: [4.3/4.4 Regression] Revision 126326 causes 12% slowdown On 05/02/08 08:16, rguenth at gcc dot gnu dot org wrote: > and dropping the final dom pass in favor of another FRE one (DOM has > weaker memory optimization but in addition does some jump threading and > cond expr combining, both of which don't happen a lot after loop > optimizations). Along these lines, I think we would really benefit from doing a thorough study of pass reordering using the techniques in GCC-ICI (GCC Summit 2008) and COLE (CGO 2008). Both have found significant improvements with different optimization pipelines. > Note that teaching DOM about the alias-oracle is very difficult and > unlikely to happen - I'd rather get rid of DOM completely. Agreed. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug c++/33738] -Wtype-limits misses a warning when comparing enums
--- Comment #6 from dnovillo at google dot com 2008-02-05 16:15 --- Subject: Re: -Wtype-limits misses a warning when comparing enums On 5 Feb 2008 11:21:26 -, manu at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > You should use OPT_Wtype_limits instead of OPT_Wextra. Ah, yes, thanks. > Also, the code could simply do: Well, I explicitly wanted to separate the decision making from the warning machinery. > And BTW, what is G_ for? That's the i18n marker. I c-n-p it from other messages in the same file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33738
[Bug tree-optimization/30194] [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs
--- Comment #19 from dnovillo at google dot com 2008-01-08 17:06 --- Subject: Re: [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs > I don't think anything is wrong with 'alias set partitioning dependent on SFT > DECL_UIDs'. If two SFTs score equal we need to discriminate them somehow. > DECL_UID is exactly the right thing to use for this. > > Note that > > 2007-10-25 Richard Guenther <[EMAIL PROTECTED]> > > ... > * tree-ssa-alias.c (mem_sym_stats): ... here and make it static. > ... > (compare_mp_info_entries): Make sort stable by disambiguating > on DECL_UID. > > might have improved the situation. Or worsened it. > > The question would be - why should the DECL_UIDs for SFTs change > spontaneously? Bother. I thought I was replying to a different PR (33237). No, I don't think I'll work on this PR. I agree with Richard's assessment. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug tree-optimization/30194] [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs
--- Comment #17 from dnovillo at google dot com 2008-01-08 16:23 --- Subject: Re: [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs On 8 Jan 2008 16:20:39 -, steven at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > Diego, > Is this something you plan to work on for GCC 4.3? I will do my best. > Does this still qualify as a "4.3 regression"? If it can't be reproduced with earlier versions, yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #15 from dnovillo at google dot com 2007-11-07 15:14 --- Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3 On 7 Nov 2007 15:05:57 -, rguenther at suse dot de <[EMAIL PROTECTED]> wrote: > It actually contains all pointed-to SFTs. But yes, we should be able > to fix this by conservatively counting VOPs (that is, rather > overestimate). I plan to look at the heuristics as soon as we settled > on a fix for the wrong-code PR33870. Remember that the partitioner cannot rely on VOPs. The very first time, they do not exist because aliases have not been computed and in subsequent passes the VOPs are many times stale because of aliasing changes. Blindly including VOPs the first time is not really workable because of the potentially huge number of them that we can generate. Prior to the partitioning scheme we used to have a scheme for trying to limit them with .GLOBAL_VAR (which now is only used when there are *no* global variables to prevent a corner case in TER). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #13 from dnovillo at google dot com 2007-11-07 13:57 --- Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3 On 7 Nov 2007 13:52:29 -, amacleod at redhat dot com <[EMAIL PROTECTED]> wrote: > There is also an issue with partitioning, but it would then hide what I > think is an important issue. > > Partitioning's problem is that it counts the number of items in the > alias set and just uses that. There is only one entry for an entire SFT > list, so it misses the other 819 in this particular list. The difficulty > is determining how many of those SFTs are actually going to be > relevant. Ideally, partitioning would share code with VOP processing so > it can see exactly how many VOPs would be generated by each MEM. Agreed. The partitioner heuristics got severely skewed when we switched alias sets to only contain the first SFT in the pointed-to structure. But that should be a relatively simple fix. > I dunno. The MEM has a very clear base, and a very clear offset, and a > very clear size, it certainly LOOKS like it should be able to figure it > out. Indeed. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2
--- Comment #14 from dnovillo at google dot com 2007-11-07 12:14 --- Subject: Re: [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2 On 7 Nov 2007 06:03:09 -, paolo dot bonzini at lu dot unisi dot ch <[EMAIL PROTECTED]> wrote: > > I don't think we want to start playing with the heuristics ;) That patch > > certainly will cause compile-time and memory usage regressions. > > Not for -O2, since the default AVG_ALIASED_VOPS is 1. For -O3 it is 3, > not huge either. You'd be surprised. AVG_ALIASED_VOPS is fairly sensitive wrt compile-time effects. You need to test the effects of this change carefully. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
[Bug tree-optimization/33572] [4.3 Regression] wrong code with -O
--- Comment #11 from dnovillo at google dot com 2007-09-30 13:41 --- Subject: Re: [4.3 Regression] wrong code with -O On 30 Sep 2007 12:41:03 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-30 12:41 > --- > Diego, we seem to have a general problem with the incremental SSA updater. > If we rename foo$ptr in > > : > # foo$ptr_16 = PHI > p_12 = foo$ptr_16; > foo$ptr_19(ab) = 0B; > p_15 = foo$ptr_16; > p_4 = foo$ptr_16; > p_5 = foo$ptr_16; > D.1781_6 = foo$ptr_16->_vptr.Foo; > D.1782_7 = *D.1781_6; > OBJ_TYPE_REF(D.1782_7;foo$ptr_16->0) (foo$ptr_16); > goto ; Is the symbol foo$ptr being marked for renaming? If so, that's wrong. A gimple register symbol cannot be marked for renaming if there are overlapping live ranges in its SSA names. We don't have a general mechanism to prevent that. Mostly because we do not keep track when OLRs are created. The generic SSA updating mechanism has no cheap way of checking that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33572
[Bug tree-optimization/33593] tree-outof-ssa moves sources of non-call exceptions past sequence points
--- Comment #3 from dnovillo at google dot com 2007-09-29 19:08 --- Subject: Re: tree-outof-ssa moves sources of non-call exceptions past sequence points On 29 Sep 2007 19:05:20 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > 1 / 0; > > that does not aways trap. on ppc an undefined value is returned. In which case tree_could_trap_p() will/should return false on this expression then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33593
[Bug tree-optimization/33562] [4.3 Regression] aggregate DSE disabled
--- Comment #9 from dnovillo at google dot com 2007-09-27 14:12 --- Subject: Re: [4.3 Regression] aggregate DSE disabled On 27 Sep 2007 14:01:18 -, rguenther at suse dot de <[EMAIL PROTECTED]> wrote: > I sort-of agree. Still DCE was able to handle tree-ssa/complex-4.c > before we removed V_MUST_DEF. Which is what I'm trying to get back. Yeah, it is somewhat tempting to make the infrastructure more powerful because you suddenly get more out of seemingly innocent passes. However, a more powerful infrastructure creates problems of its own, it needs to be maintained and it causes slowdowns even in passes that do not need all the expressive power. > As "good enough" UD web it would be nice to have only single VDEFs on > stores (I don't care for clobbers at call sites). Though finding the > optimal static partitioning to ensure this is probably hard? Yeah, that is the whole motivation behind the dynamic aspects of mem-ssa, but getting it right has proven tricky. Unfortunately, I have not had time to come back to that idea in some time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33562
[Bug tree-optimization/33562] [4.3 Regression] aggregate DSE disabled
--- Comment #7 from dnovillo at google dot com 2007-09-27 13:48 --- Subject: Re: [4.3 Regression] aggregate DSE disabled On 27 Sep 2007 13:42:11 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > Diego, it sucks that we need to jump through hoops to get V_MUST_DEF "back". Unless we can prove that it is impossible to implement DSE any other way, I would prefer to keep virtual SSA as simple as possible. It's meant as a safety net and a "good enough" UD web for passes that do not care for being too aggressive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33562
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #5 from dnovillo at google dot com 2007-08-17 20:37 --- Subject: Re: [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around On 8/17/07 4:34 PM, pinskia at gcc dot gnu dot org wrote: > --- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-17 20:34 > --- > Oh you are correct but this still worked in 4.1.1 though, I have not looked > into what changed between 4.1.1 and 4.2.0 with respect of scev yet. Since you are looking, two things to check for: (1) IL representation for the pointer subtraction, and (2) SCEV may have returned an unknown chrec back in 4.1. Or maybe we still didn't consider pointers to not-wrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug tree-optimization/33099] [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around
--- Comment #3 from dnovillo at google dot com 2007-08-17 20:27 --- Subject: Re: [4.2 Regression] Scalar evolutions confusing VRP with pointer values that wrap around On 8/17/07 4:20 PM, pinskia at gcc dot gnu dot org wrote: > --- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-17 20:20 > --- > Exposed by: > 2006-02-07 Jeff Law <[EMAIL PROTECTED]> > > > Which added VRP after IV-OPTs. No, no that is completely unrelated. This happens in the first VRP pass. It's all inside adjust_range_with_scev which specifically calls scalar evolutions code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33099
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #30 from dnovillo at google dot com 2007-07-04 11:22 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On 7/3/07 11:28 PM, mmitchel at gcc dot gnu dot org wrote: > --- Comment #29 from mmitchel at gcc dot gnu dot org 2007-07-04 03:28 > --- > Diego, does this problem still exist on the 4.2 branch? I see that you > checked > in a patch, which you suggest may not be a complete fix, but does this test > case still fail? Yes, the problem still exists on 4.2 and mainline. The patch is valid in that it fixes a codegen deficiency, but it only works around this bug. The test case does not fail anymore, and getting another one to fail may be tricky (it's a fairly rare bug, unfortunately). A real fix is in the works, but it's not clear when it might be ready. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #27 from dnovillo at google dot com 2007-06-19 17:39 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On 6/19/07 1:26 PM, rth at gcc dot gnu dot org wrote: > --- Comment #26 from rth at gcc dot gnu dot org 2007-06-19 17:26 --- > (In reply to comment #10) >> Talked to Dan Berlin and Diego Novillo here at Google. They told me >> that all locals are promoted to function scope. > > That *only* applies to register variables, not stack variables. Yes, but our GIMPLE optimizers don't know that and we do not have a way of enforcing that in GIMPLE. There just are no scope boundaries in the SSA web. So, the end result is that in SSA we only have function scope. > We very very much want to preserve scope of stack variables, because > we very very much want to share stack space between stack variables > of different scopes. Failure to do so causes bad interactions with > inlining, and causes stack space consumtion to grow to unacceptable > levels. I.e. you can't build kernels anymore. Agreed. We have to find a way of either tying the hands of code motion transformations by making them use the SSA web *and* the TREE_BLOCKs, or make stack slot sharing aware of live ranges. Right now we have the unfortunate situation that an optimizer is making a valid transformation which breaks the scope assumption that stack sharing uses. I am not sure if it would be practical to force code motion optimizations to use anything other than the SSA web to do their analysis. Perhaps we could force scopes by building barriers on the SSA web itself (say, by putting PHI nodes at scope boundaries, or something). Alternatively, we could incorporate live-range analysis to stack slot sharing. That way, if code motion creates undue stack slot pressure, we would merely emit suboptimal code, instead of wrong code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug tree-optimization/32390] tree-ssa-math-opts.c performs too many IL scans
--- Comment #2 from dnovillo at google dot com 2007-06-18 14:00 --- Subject: Re: tree-ssa-math-opts.c performs too many IL scans On 6/18/07 9:56 AM, rguenth at gcc dot gnu dot org wrote: > --- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-18 13:56 > --- > All three transformations are done at different stages of the optimization > pipeline due to various reasons. We need a better explanation than this. Uros agreed to summarize the IRC discussion to close this issue. It'd be useful if we keep that same discussion on the source code itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32390
