[Bug lto/66229] LTO fails with -fauto-profile on mcf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66229 Dehao Chen changed: What|Removed |Added CC||dehao at google dot com --- Comment #1 from Dehao Chen --- We have not tested autofdo with lto at all. So I'm not surprised that this fails. Please feel free to send out patches to fix this. Thanks, Dehao
[Bug ipa/65972] ICE after applying a patch to enable verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972
--- Comment #5 from Dehao Chen ---
Could you try if the following patch fixes the bug?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision 223204)
+++ gcc/auto-profile.c (working copy)
@@ -1470,6 +1470,7 @@ afdo_vpt_for_early_inline (stmt_set *promoted_stmt
if (has_vpt)
{
optimize_inline_calls (current_function_decl);
+ update_ssa (TODO_update_ssa);
return true;
}
[Bug tree-optimization/58619] ICE building in gen_combined_adhoc_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58619 Dehao Chen changed: What|Removed |Added CC||dehao at google dot com --- Comment #3 from Dehao Chen --- This is a bug when updating block during tree-inline. Basically, it is legal for *n to be NULL. E.g. When gimple_block(id->gimple_call) is NULL, remap_blocks_to_null will be called to set *n to NULL. The problem is that we should check this before calling COMBINE_LOCATION_DATA, which assumes block is not NULL. The following patch can fix the problem: Index: gcc/tree-inline.c === --- gcc/tree-inline.c(revision 203208) +++ gcc/tree-inline.c(working copy) @@ -2090,7 +2090,10 @@ copy_phis_for_bb (basic_block bb, copy_body_data * n = (tree *) pointer_map_contains (id->decl_map, LOCATION_BLOCK (locus)); gcc_assert (n); - locus = COMBINE_LOCATION_DATA (line_table, locus, *n); + if (*n) +locus = COMBINE_LOCATION_DATA (line_table, locus, *n); + else +locus = LOCATION_LOCUS (locus); } else locus = LOCATION_LOCUS (locus);
[Bug middle-end/54782] [4.8 Regression] ICE: in change_scope, at final.c:1543 with -O -ffast-math -ftree-parallelize-loops=2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54782 --- Comment #2 from Dehao Chen 2012-10-03 16:47:23 UTC --- Thanks for reporting this problem. The root cause has been identified that phi_arg_location is not correctly updated in move_block_to_fn. A patch is on the way. BTW, how can I assign this patch to me? Looks like there is no such a button in my view.
[Bug middle-end/54649] [4.8 Regression] Go bootstrap failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54649 Dehao Chen changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Dehao Chen 2012-10-02 16:37:44 UTC --- This bug has been fixed by: URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191614 Log: 2012-09-21 Dehao Chen PR go/54649 * tree-eh.c (lower_try_finally_dup_block): Set the correct block for stmts in the duplicated EH block.
[Bug middle-end/54759] [4.8 regression] segfault for gcc.dg/vect/pr49093.c on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54759 Dehao Chen changed: What|Removed |Added CC||dehao at google dot com --- Comment #1 from Dehao Chen 2012-09-30 19:05:05 UTC --- Thanks for reporting the bug. I prepared a patch to fix this: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01997.html Could you help verify if it is fixed by this? Thanks, Dehao
[Bug tree-optimization/54735] [4.8 Regression] Segmentation fault in walk_aliased_vdefs_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735 Dehao Chen changed: What|Removed |Added CC||dehao at google dot com --- Comment #3 from Dehao Chen 2012-09-28 20:51:07 UTC --- r191747 should not increase the memory consumption. Instead, it'll only speedup compilation. I tried to compile the testcase without the patch, the memory consumption still increase, but very slowly (it took around 30 minutes to climb up to 1.8G)
[Bug bootstrap/54719] Bootstrap stuck in stage1 with message "checking for compiler with PCH support"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54719 --- Comment #1 from Dehao Chen 2012-09-26 14:25:25 UTC --- Hi, Dodji, Could you help verify if this problem is solved by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191706 ? If yes, then it should be a duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645 Thanks, Dehao
[Bug middle-end/54650] [4.8 Regression] libgomp regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54650 Dehao Chen changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Dehao Chen 2012-09-26 01:14:45 UTC --- This problem was fixed by r191680
[Bug middle-end/54704] [4.8 Regression] three-fold increase in compile-time between r191483 and r191569
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54704 Dehao Chen changed: What|Removed |Added CC||dehao at google dot com --- Comment #7 from Dehao Chen 2012-09-25 19:34:33 UTC --- Yes, this is bug in the hash function. Your fix should be correct, as can be inferred from the location_adhoc_data_eq function. I'll test the patch now. Thanks, Dehao
[Bug libgomp/54650] libgomp regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54650 --- Comment #1 from Dehao Chen 2012-09-21 01:23:36 UTC --- This error should be a bug exposed by this patch. In expand_omp_taskreg, it calls move_sese_region_to_fn with gimple_block(entry_stmt) as the root of the block tree. However, there is an edge inside the region that has the root's sibling as its goto_block. As a result, the block get escaped when numbering the blocks. This bug does not expose before because he goto_block was set NULL. The block_location patch reserved the value for the goto_block, thus exposed he problem.
[Bug libgomp/54650] New: libgomp regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54650 Bug #: 54650 Summary: libgomp regression Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: de...@google.com This problem is reported in: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01441.html The bug was introduced in r191494 [macbook] f90/bug% gfc -O3 -g -fopenmp /opt/gcc/work/libgomp/testsuite/libgomp.fortran/reduction1.f90 /opt/gcc/work/libgomp/testsuite/libgomp.fortran/reduction1.f90: In function 'MAIN__._omp_fn.0': /opt/gcc/work/libgomp/testsuite/libgomp.fortran/reduction1.f90:22:0: internal compiler error: in change_scope, at final.c:1543 !$omp & reduction (+:i, ia, r, ra, d, da, c, ca) The backtrace is #0 fancy_abort (file=0x100a7b376 "../../work/gcc/final.c", line=1543, function=0x100b418b3 "change_scope") at ../../work/gcc/diagnostic.c:1010 #1 0x00010045f9f9 in change_scope (orig_insn=, s1=, s2=) at ../../work/gcc/final.c:1543 #2 0x000100463c40 in final_start_function (first=, file=, optimize_p=) at ../../work/gcc/final.c:1613 #3 0x000100465761 in rest_of_handle_final () at ../../work/gcc/final.c:4291 #4 0x0001006486ea in execute_one_pass (pass=) at ../../work/gcc/passes.c:2206 #5 0x000100648afd in execute_pass_list (pass=) at ../../work/gcc/passes.c:2261 #6 0x000100648b0f in execute_pass_list (pass=) at ../../work/gcc/passes.c:2262 #7 0x000100648b0f in execute_pass_list (pass=) at ../../work/gcc/passes.c:2262 #8 0x000100365f4b in expand_function (node=) at ../../work/gcc/cgraphunit.c:1609 #9 0x0001003680ba in compile () at ../../work/gcc/cgraphunit.c:1714 #10 0x00010036870f in finalize_compilation_unit () at ../../work/gcc/cgraphunit.c:2089 #11 0x0001005e0f27 in write_global_declarations () at ../../work/gcc/langhooks.c:323 #12 0x0001007047f1 in compile_file () at ../../work/gcc/toplev.c:560 #13 0x00010070663c in toplev_main (argc=, argv=) at ../../work/gcc/toplev.c:1863 #14 0x00010e14 in start ()
[Bug go/54649] Go bootstrap failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54649 --- Comment #1 from Dehao Chen 2012-09-21 01:15:17 UTC --- This problem is caused by the inconsistency between r191338 and r191494, both of which handle the debug info. The problem is that when we set the line number for stmts in the finally block, we don't want to change its block info. Otherwise, we might set an empty block to a call statement.
[Bug go/54649] New: Go bootstrap failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54649
Bug #: 54649
Summary: Go bootstrap failed
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
AssignedTo: i...@airs.com
ReportedBy: de...@google.com
In r191494, the bootstrap for go is broken.
Ian has a small testcase to reproduce this:
#include
std::string
f(bool is_string, bool is_constant)
{
if (is_string)
{
std::string left_string;
std::string right_string;
if (is_constant)
{
return left_string + right_string;
}
}
return "";
}
When I compile that with current mainline with -O -g I get a crash
(the backtrace is a local patch of mine):
foo.cc: In function ‘std::string f(bool, bool)’:
foo.cc:17:1: internal compiler error: tree check: expected block, have
function_decl in change_scope, at final.c:1544
}
^
0xe388bd tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../trunk/gcc/tree.c:8892
0x50c495 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../trunk/gcc/tree.h:3659
0x9372a1 change_scope
../../trunk/gcc/final.c:1544
0x937646 reemit_insn_block_notes
../../trunk/gcc/final.c:1613
0x937822 final_start_function(rtx_def*, _IO_FILE*, int)
../../trunk/gcc/final.c:1670
0x93c6ad rest_of_handle_final
../../trunk/gcc/final.c:4291
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug rtl-optimization/54645] [4.8 Regression] Many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645 Dehao Chen changed: What|Removed |Added CC||dehao at google dot com --- Comment #6 from Dehao Chen 2012-09-21 00:51:27 UTC --- This problem is caused by r191494. The cause of the problem is: when reading PCH data, the line_table is also read from PCH files. But the location_adhoc_data_map is not managed by GC, thus is not read in from PCH file (only a pointer is read in). To solve this problem, we'll need to move location_adhoc_data_map into GC. I'll have a patch to solve this problem.
