[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-15 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #37 from Richard Biener rguenth at gcc dot gnu.org 2013-01-15 
14:31:39 UTC ---

According to gcc-regression this issue has fixed itself by whatever patch.

Double-checked with a pristine trunk LTO profiledbootstrap.


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-14 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #34 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 
13:42:36 UTC ---

static void

output_node_opt_summary (struct output_block *ob,

 struct cgraph_node *node,

 lto_symtab_encoder_t encoder)

{

...

  gcc_assert (EXPR_LOCATION (map-new_tree) == UNKNOWN_LOCATION);



isn't recursively checking EXPR_LOCATION.



Index: gcc/lto-cgraph.c

===

--- gcc/lto-cgraph.c(revision 195144)

+++ gcc/lto-cgraph.c(working copy)

@@ -1492,6 +1492,22 @@ output_edge_opt_summary (struct output_b

 {

 }



+static tree

+verify_no_location (tree *tp, int *walk_subtrees, void *)

+{

+  if (EXPR_P (*tp))

+gcc_assert (EXPR_LOCATION (*tp) == UNKNOWN_LOCATION);

+  else

+*walk_subtrees = 0;

+  return NULL_TREE;

+}

+

+static void

+verify_no_location (tree expr)

+{

+  walk_tree (expr, verify_no_location_r, NULL, NULL);

+}

+

 /* Output optimization summary for NODE to OB.  */



 static void

@@ -1536,7 +1552,9 @@ output_node_opt_summary (struct output_b

  mechanism to store function local declarations into summaries.  */

   gcc_assert (parm);

   streamer_write_uhwi (ob, parm_num);

-  gcc_assert (EXPR_LOCATION (map-new_tree) == UNKNOWN_LOCATION);

+#ifdef ENABLE_CHECKING

+  verify_no_location (map-new_tree);

+#endif

   stream_write_tree (ob, map-new_tree, true);

   bp = bitpack_create (ob-main_stream);

   bp_pack_value (bp, map-replace_p, 1);


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-14 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #35 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 
13:48:47 UTC ---

And the following may fix it at a single central place.



Index: gcc/tree-inline.c

===

--- gcc/tree-inline.c   (revision 195144)

+++ gcc/tree-inline.c   (working copy)

@@ -2563,11 +2563,11 @@ setup_one_parameter (copy_body_data *id,

 basic_block bb, tree *vars)

 {

   gimple init_stmt = NULL;

-  tree var;

-  tree rhs = value;

+  tree var, rhs;

   tree def = (gimple_in_ssa_p (cfun)

  ? ssa_default_def (id-src_cfun, p) : NULL);



+  rhs = value = unshare_expr_without_location (value);

   if (value

value != error_mark_node

!useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value)))


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-14 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #36 from Richard Biener rguenth at gcc dot gnu.org 2013-01-14 
13:50:49 UTC ---

Or more conservative, dropping less locations:



Index: gcc/tree-inline.c

===

--- gcc/tree-inline.c   (revision 195144)

+++ gcc/tree-inline.c   (working copy)

@@ -5190,7 +5190,7 @@ tree_function_versioning (tree old_decl,

replace_info = (*tree_map)[i];

if (replace_info-replace_p)

  {

-   tree op = replace_info-new_tree;

+   tree op = unshare_expr_without_location (replace_info-new_tree);

if (!replace_info-old_tree)

  {

int i = replace_info-parm_num;

@@ -5199,18 +5199,10 @@ tree_function_versioning (tree old_decl,

  i --;

replace_info-old_tree = parm;

  }

-

-

-   STRIP_NOPS (op);

-

-   if (TREE_CODE (op) == VIEW_CONVERT_EXPR)

- op = TREE_OPERAND (op, 0);

-

gcc_assert (TREE_CODE (replace_info-old_tree) == PARM_DECL);

+

init = setup_one_parameter (id, replace_info-old_tree,

-   replace_info-new_tree, id.src_fn,

-   NULL,

-   vars);

+   op, id.src_fn, NULL, vars);

if (init)

  init_stmts.safe_push (init);

  }


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-11 Thread hubicka at ucw dot cz


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #33 from Jan Hubicka hubicka at ucw dot cz 2013-01-11 17:36:48 
UTC ---

 

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792

 

 --- Comment #32 from H.J. Lu hjl.tools at gmail dot com 2013-01-10 19:36:08 
 UTC ---

 (In reply to comment #30)

  LTO profiled-bootstrap revals:

  

  /space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan':

  /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location 
  references

  block not in block tree

   reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED)

   ^

  ee

  fmt_351 = ee;

  

  /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: internal compiler 
  error:

  verify_gimple failed

  

  this is a STRING_CST node.  Needs to be tracked down ... more IPA stuff 
  needs

  to use copy_tree_without_location.

 

 I think this BLOCK comes from LTO streamer.

I guess we could add assert to lto streamer to not read any local blocks during

WPA.  I will try that.



Honza

 

 -- 

 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 bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-10 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org

   |gnu.org |



--- Comment #24 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 
11:29:16 UTC ---

Created attachment 29139

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29139

patch to verify locations as LTO expects them



This verifies that all stmts locations (missing expr locations) have a BLOCK

that is in the functions BLOCK tree (_not_ counting abstract origins, as LTO

does not stream the abstract part of the BLOCK tree!).  It fires on trivial

inlining testcases which means that LTO will end up with the issue you

are seeing.



Ugh.  Investigating.


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-10 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



  Attachment #29139|0   |1

is obsolete||



--- Comment #25 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 
12:15:41 UTC ---

Created attachment 29140

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29140

updated patch with fixes



Fix for virtual operands (shouldn't be relevant for LTO).  My guess would still

be IPA opts, so can you check if it triggers?  I'm doing regular bootstrap /

testing and will commit the virtuals fix independently.


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-10 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #26 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 
13:42:33 UTC ---

Author: rguenth

Date: Thu Jan 10 13:42:27 2013

New Revision: 195084



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195084

Log:

2013-01-10  Richard Biener  rguent...@suse.de



PR bootstrap/55792

* tree-into-ssa.c (rewrite_add_phi_arguments): Do not set

locations for virtual PHI arguments.

(rewrite_update_phi_arguments): Likewise.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/tree-into-ssa.c


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-10 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



  Attachment #29140|0   |1

is obsolete||



--- Comment #27 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 
14:07:55 UTC ---

Created attachment 29141

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29141

updated checker



Also verify expressions.  Bootstrapped ok, target libs building now, testing

pending.



I'll give it a LTO profiledbootstrap try as well ... if that's not it then

the issue must be elsewhere :(


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-10 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #28 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 
14:11:43 UTC ---

Another possibility lies in DEBUG stmts which we do not consider at all ...

(in the checker, that is).


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-10 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #29 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 
15:28:38 UTC ---

(In reply to comment #27)

 Created attachment 29141 [details]

 updated checker

 

 Also verify expressions.  Bootstrapped ok, target libs building now, testing

 pending.

 

 I'll give it a LTO profiledbootstrap try as well ... if that's not it then

 the issue must be elsewhere :(



Besides a few fortran ICEs in the testsuite a regular bootstrap and regtest

went ok with this version.



The Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs which have a location

with bogus BLOCK.



FAIL: gfortran.dg/class_array_15.f03  -O0  (internal compiler error)

FAIL: gfortran.dg/class_array_15.f03  -O0  (test for excess errors)

WARNING: gfortran.dg/class_array_15.f03  -O0  compilation failed to produce

exec

utable

FAIL: gfortran.dg/typebound_operator_13.f03  -O0  (internal compiler error)

FAIL: gfortran.dg/typebound_operator_13.f03  -O0  (test for excess errors)

WARNING: gfortran.dg/typebound_operator_13.f03  -O0  compilation failed to

produ

ce executable

FAIL: gfortran.dg/typebound_operator_7.f03  -O0  (internal compiler error)

FAIL: gfortran.dg/typebound_operator_7.f03  -O0  (test for excess errors)

WARNING: gfortran.dg/typebound_operator_7.f03  -O0  compilation failed to

produc

e executable

FAIL: gfortran.dg/typebound_operator_8.f03  -O0  (internal compiler error)

FAIL: gfortran.dg/typebound_operator_8.f03  -O0  (test for excess errors)

WARNING: gfortran.dg/typebound_operator_8.f03  -O0  compilation failed to

produc

e executable


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-10 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #30 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10 
15:34:39 UTC ---

LTO profiled-bootstrap revals:



/space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan':

/space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location references

block not in block tree

 reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED)

 ^

ee

fmt_351 = ee;



/space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: internal compiler error:

verify_gimple failed



this is a STRING_CST node.  Needs to be tracked down ... more IPA stuff needs

to use copy_tree_without_location.


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-10 Thread hjl.tools at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792

--- Comment #31 from H.J. Lu hjl.tools at gmail dot com 2013-01-10 17:03:13 
UTC ---
(In reply to comment #30)
 LTO profiled-bootstrap revals:
 
 /space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan':
 /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location 
 references
 block not in block tree
  reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED)
  ^
 ee
 fmt_351 = ee;

This is the same problem in comment #13:

In file included from :4457:0:
/export/gnu/import/git/gcc/gcc/reginfo.c: In function ‘reg_scan’:
/export/gnu/import/git/gcc/gcc/reginfo.c:1015:0: error: location references
block not in block tree
 reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED)
 ^
ee
fmt_388 = ee;

/export/gnu/import/git/gcc/gcc/reginfo.c:1015:0: internal compiler error:
verify_gimple failed
0x9c7dc8 verify_gimple_in_cfg(function*)
/export/gnu/import/git/gcc/gcc/tree-cfg.c:4726
0x8ad9e0 execute_function_todo
/export/gnu/import/git/gcc/gcc/passes.c:1968
0x8acd04 do_per_function
/export/gnu/import/git/gcc/gcc/passes.c:1703
0x8adb04 execute_todo
/export/gnu/import/git/gcc/gcc/passes.c:2001
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-10 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #32 from H.J. Lu hjl.tools at gmail dot com 2013-01-10 19:36:08 
UTC ---

(In reply to comment #30)

 LTO profiled-bootstrap revals:

 

 /space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan':

 /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: error: location 
 references

 block not in block tree

  reg_scan (rtx f, unsigned int nregs ATTRIBUTE_UNUSED)

  ^

 ee

 fmt_351 = ee;

 

 /space/rguenther/src/svn/trunk/gcc/reginfo.c:1015:0: internal compiler error:

 verify_gimple failed

 

 this is a STRING_CST node.  Needs to be tracked down ... more IPA stuff needs

 to use copy_tree_without_location.



I think this BLOCK comes from LTO streamer.


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-09 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #18 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
09:31:45 UTC ---

(In reply to comment #17)

 gimple_location is duplicated by:

 

 #1  0x00751f32 in gimple_copy (stmt=0x7fffe8d75a00)

 at /export/gnu/import/git/gcc/gcc/gimple.c:2205

 #2  0x009c960d in gimple_duplicate_bb (bb=0x7fffe8d768f0)

 at /export/gnu/import/git/gcc/gcc/tree-cfg.c:5397

 #3  0x005b27a5 in duplicate_block (bb=0x7fffe8d768f0, 

 e=0x7fffe8d793f0, after=0x7fffe8d76888)

 at /export/gnu/import/git/gcc/gcc/cfghooks.c:1012

 #4  0x0099c511 in tail_duplicate ()

 at /export/gnu/import/git/gcc/gcc/tracer.c:323

 #5  0x0099c765 in tracer ()

 at /export/gnu/import/git/gcc/gcc/tracer.c:380

 #6  0x008ae0e6 in execute_one_pass (pass=0x16d18a0 pass_tracer)

 at /export/gnu/import/git/gcc/gcc/passes.c:2335

 #7  0x008ae2da in execute_pass_list (pass=0x16d18a0 pass_tracer)

 at /export/gnu/import/git/gcc/gcc/passes.c:2383

 #8  0x008ae30b in execute_pass_list (

 pass=0x16d07e0 pass_all_optimizations)

 at /export/gnu/import/git/gcc/gcc/passes.c:2384

 #9  0x005da366 in expand_function (node=0x717536f0)

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

 #10 0x005da821 in expand_all_functions ()

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

 (gdb) p copy

 $176 = (gimple) 0x7fffe8e0a320

 (gdb) 



The BLOCK of the location is kept live by being referenced by the stmt

copy (what kind is the stmt?  the only stmt not well handled seems to

be CLOBBERs)



 Later, the original location is removed:

 

 #0  remove_unused_locals ()

 at /export/gnu/import/git/gcc/gcc/tree-ssa-live.c:793

 #1  0x008ad5cb in execute_function_todo (data=0x8800)

 at /export/gnu/import/git/gcc/gcc/passes.c:1952

 #2  0x008ac965 in do_per_function (

 callback=0x8ad4ae execute_function_todo(void*), data=0x8800)

 at /export/gnu/import/git/gcc/gcc/passes.c:1703

 #3  0x008ad765 in execute_todo (flags=34816)

 at /export/gnu/import/git/gcc/gcc/passes.c:2001

 #4  0x008ae175 in execute_one_pass (

 pass=0x16d3220 pass_cleanup_cfg_post_optimizing)

 at /export/gnu/import/git/gcc/gcc/passes.c:2349

 #5  0x008ae2da in execute_pass_list (

 pass=0x16d3220 pass_cleanup_cfg_post_optimizing)

 at /export/gnu/import/git/gcc/gcc/passes.c:2383

 #6  0x005da366 in expand_function (node=0x717536f0)

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

 #7  0x005da821 in expand_all_functions ()

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

 

 and freed.



You probably mean BLOCK - it should be still live as referenced from

the stmt, or cleaned from the stmt if it was a debug stmt.



  Then we copy the freed gimple_location:

 

 #0  expand_gimple_stmt_1 (stmt=0x7fffe8e0a320)

 at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2202

 #1  0x005a7786 in expand_gimple_stmt (stmt=0x7fffe8e0a320)

 at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2305

 #2  0x005ad975 in expand_gimple_basic_block (bb=0x7fffe8d76888, 

 disable_tail_calls=false)

 at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4084

 #3  0x005af426 in gimple_expand_cfg ()

 at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4603

 #4  0x008ae0e6 in execute_one_pass (pass=0x16ce300 pass_expand)

 at /export/gnu/import/git/gcc/gcc/passes.c:2335

 #5  0x008ae2da in execute_pass_list (pass=0x16ce300 pass_expand)

 at /export/gnu/import/git/gcc/gcc/passes.c:2383

 #6  0x005da366 in expand_function (node=0x717536f0)

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

 #7  0x005da821 in expand_all_functions ()

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

 #8  0x005db2ab in compile ()

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043

 #9  0x0053c60a in lto_main ()

 at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390

 #10 0x00999401 in compile_file ()

 at /export/gnu/import/git/gcc/gcc/toplev.c:545


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-09 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #19 from H.J. Lu hjl.tools at gmail dot com 2013-01-09 16:11:06 
UTC ---

The BLOCK tree node is cleared by



(gdb) bt

#0  0x00336b4882ee in __memset_sse2 () from /lib64/libc.so.6

#1  0x00545fdf in clear_marks ()

at /export/gnu/import/git/gcc/gcc/ggc-page.c:1815

#2  0x00546621 in ggc_collect ()

at /export/gnu/import/git/gcc/gcc/ggc-page.c:2086

#3  0x008ad816 in execute_todo (flags=2102)

at /export/gnu/import/git/gcc/gcc/passes.c:2023

#4  0x008ae175 in execute_one_pass (pass=0x17b9c70)

at /export/gnu/import/git/gcc/gcc/passes.c:2349

#5  0x008ae2da in execute_pass_list (pass=0x17b9c70)

at /export/gnu/import/git/gcc/gcc/passes.c:2383

#6  0x008ae30b in execute_pass_list (

pass=0x16d07e0 pass_all_optimizations)

at /export/gnu/import/git/gcc/gcc/passes.c:2384

#7  0x005da366 in expand_function (node=0x716f5378)

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

#8  0x005da821 in expand_all_functions ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

#9  0x005db2ab in compile ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043

#10 0x0053c60a in lto_main ()

at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390

#11 0x00999401 in compile_file ()

---Type return to continue, or q return to quit---

at /export/gnu/import/git/gcc/gcc/toplev.c:545

#12 0x0099b3e4 in do_compile ()

at /export/gnu/import/git/gcc/gcc/toplev.c:1878

#13 0x0099b54f in toplev_main (argc=28, argv=0x7fffdc78)

at /export/gnu/import/git/gcc/gcc/toplev.c:1954

#14 0x00fff958 in main (argc=28, argv=0x7fffdc78)

at /export/gnu/import/git/gcc/gcc/main.c:36

(gdb)



When we remap a block:

static void

remap_block (tree *block, copy_body_data *id)

{

  tree old_block;

  tree new_block;



  /* Make the new block.  */

  old_block = *block;

  new_block = make_node (BLOCK);

  TREE_USED (new_block) = TREE_USED (old_block);

  BLOCK_ABSTRACT_ORIGIN (new_block) = old_block;

  BLOCK_SOURCE_LOCATION (new_block) = BLOCK_SOURCE_LOCATION (old_block);

  BLOCK_NONLOCALIZED_VARS (new_block)

= vec_safe_copy (BLOCK_NONLOCALIZED_VARS (old_block));

  *block = new_block;



  /* Remap its variables.  */

  BLOCK_VARS (new_block) = remap_decls (BLOCK_VARS (old_block),

BLOCK_NONLOCALIZED_VARS (new_block),

id);



we didn't register it with GC root.


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-09 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #20 from H.J. Lu hjl.tools at gmail dot com 2013-01-09 17:12:45 
UTC ---

we put the remapped block in line_table:



#0  0x0101d8cf in get_combined_adhoc_loc (set=0x77ffc000, 

locus=968541695, data=0x7fffe8d6fe60)

at /export/gnu/import/git/gcc/libcpp/line-map.c:146

#1  0x009f839d in gimple_set_block (g=0x7fffe8d759b0, 

block=0x7fffe8d6fe60) at /export/gnu/import/git/gcc/gcc/gimple.h:1226

#2  0x00a016fd in remap_gimple_stmt (stmt=0x7fffe910e0a0, 

id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:1473

#3  0x00a01a04 in copy_bb (id=0x7fffd900, bb=0x7fffe910c888, 

frequency_scale=100, count_scale=1779)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:1539

#4  0x00a03f56 in copy_cfg_body (id=0x7fffd900, count=48912247, 

frequency_scale=100, entry_block_map=0x7138aaf8, 

exit_block_map=0x7fffe8d58270, blocks_to_copy=0x0, new_entry=0x0)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:2259

#5  0x00a047fa in copy_body (id=0x7fffd900, count=48912247, 

frequency_scale=100, entry_block_map=0x7138aaf8, 

exit_block_map=0x7fffe8d58270, blocks_to_copy=0x0, new_entry=0x0)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:2457

#6  0x00a0881e in expand_call_inline (bb=0x7138aaf8, 

stmt=0x71390980, id=0x7fffd900)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:4041

#7  0x00a08c6f in gimple_expand_calls_inline (bb=0x7138aaf8, 

id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:4147



But tree node in line_table is ignored by GC.


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-09 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #21 from Richard Biener rguenth at gcc dot gnu.org 2013-01-09 
18:20:32 UTC ---

(In reply to comment #19)

 The BLOCK tree node is cleared by

 

 (gdb) bt

 #0  0x00336b4882ee in __memset_sse2 () from /lib64/libc.so.6

 #1  0x00545fdf in clear_marks ()

 at /export/gnu/import/git/gcc/gcc/ggc-page.c:1815

 #2  0x00546621 in ggc_collect ()

 at /export/gnu/import/git/gcc/gcc/ggc-page.c:2086

 #3  0x008ad816 in execute_todo (flags=2102)

 at /export/gnu/import/git/gcc/gcc/passes.c:2023

 #4  0x008ae175 in execute_one_pass (pass=0x17b9c70)

 at /export/gnu/import/git/gcc/gcc/passes.c:2349

 #5  0x008ae2da in execute_pass_list (pass=0x17b9c70)

 at /export/gnu/import/git/gcc/gcc/passes.c:2383

 #6  0x008ae30b in execute_pass_list (

 pass=0x16d07e0 pass_all_optimizations)

 at /export/gnu/import/git/gcc/gcc/passes.c:2384

 #7  0x005da366 in expand_function (node=0x716f5378)

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

 #8  0x005da821 in expand_all_functions ()

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

 #9  0x005db2ab in compile ()

 at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043

 #10 0x0053c60a in lto_main ()

 at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390

 #11 0x00999401 in compile_file ()

 ---Type return to continue, or q return to quit---

 at /export/gnu/import/git/gcc/gcc/toplev.c:545

 #12 0x0099b3e4 in do_compile ()

 at /export/gnu/import/git/gcc/gcc/toplev.c:1878

 #13 0x0099b54f in toplev_main (argc=28, argv=0x7fffdc78)

 at /export/gnu/import/git/gcc/gcc/toplev.c:1954

 #14 0x00fff958 in main (argc=28, argv=0x7fffdc78)

 at /export/gnu/import/git/gcc/gcc/main.c:36

 (gdb)

 

 When we remap a block:

 static void

 remap_block (tree *block, copy_body_data *id)

 {

   tree old_block;

   tree new_block;

 

   /* Make the new block.  */

   old_block = *block;

   new_block = make_node (BLOCK);

   TREE_USED (new_block) = TREE_USED (old_block);

   BLOCK_ABSTRACT_ORIGIN (new_block) = old_block;

   BLOCK_SOURCE_LOCATION (new_block) = BLOCK_SOURCE_LOCATION (old_block);

   BLOCK_NONLOCALIZED_VARS (new_block)

 = vec_safe_copy (BLOCK_NONLOCALIZED_VARS (old_block));

   *block = new_block;

 

   /* Remap its variables.  */

   BLOCK_VARS (new_block) = remap_decls (BLOCK_VARS (old_block),

 BLOCK_NONLOCALIZED_VARS (new_block),

 id);

 

 we didn't register it with GC root.



Remapped blocks are supposed to be linked into the BLOCK tree of the

destination.  What's the backtrace of this remap_block?


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-09 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #22 from H.J. Lu hjl.tools at gmail dot com 2013-01-09 18:37:10 
UTC ---

(In reply to comment #21)

 Remapped blocks are supposed to be linked into the BLOCK tree of the



It didn't happen.



 destination.  What's the backtrace of this remap_block?



Breakpoint 5, remap_block (block=0x7fffd580, id=0x7fffd900)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:624

624  BLOCK_VARS (new_block) = remap_decls (BLOCK_VARS (old_block),

(gdb) bt

#0  remap_block (block=0x7fffd580, id=0x7fffd900)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:624

#1  0x009fe52a in remap_blocks (block=0x7fffe9107550, 

id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:645

#2  0x009fe586 in remap_blocks (block=0x7fffe9107500, 

id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648

#3  0x009fe586 in remap_blocks (block=0x7fffe91074b0, 

id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648

#4  0x009fe586 in remap_blocks (block=0x7fffe9107460, 

id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648

#5  0x009fe586 in remap_blocks (block=0x7fffe9107410, 

id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:648

#6  0x00a082fc in expand_call_inline (bb=0x7138aaf8, 

stmt=0x71390980, id=0x7fffd900)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:3958

#7  0x00a08c6f in gimple_expand_calls_inline (bb=0x7138aaf8, 

id=0x7fffd900) at /export/gnu/import/git/gcc/gcc/tree-inline.c:4147

#8  0x00a0924b in optimize_inline_calls (fn=0x7fffec94b300)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:4301

#9  0x007d2f1e in inline_transform (node=0x717536f0)

at /export/gnu/import/git/gcc/gcc/ipa-inline-transform.c:418

#10 0x008adbe3 in execute_one_ipa_transform_pass (node=0x717536f0, 

ipa_pass=0x16cfc80 pass_ipa_inline)

---Type return to continue, or q return to quit---

at /export/gnu/import/git/gcc/gcc/passes.c:2177

#11 0x008add31 in execute_all_ipa_transforms ()

at /export/gnu/import/git/gcc/gcc/passes.c:2213

#12 0x005da348 in expand_function (node=0x717536f0)

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1634

#13 0x005da821 in expand_all_functions ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

#14 0x005db2ab in compile ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043

#15 0x0053c60a in lto_main ()

at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390

#16 0x00999401 in compile_file ()

at /export/gnu/import/git/gcc/gcc/toplev.c:545

#17 0x0099b3e4 in do_compile ()

at /export/gnu/import/git/gcc/gcc/toplev.c:1878

#18 0x0099b54f in toplev_main (argc=28, argv=0x7fffdc78)

at /export/gnu/import/git/gcc/gcc/toplev.c:1954

#19 0x00fff958 in main (argc=28, argv=0x7fffdc78)

at /export/gnu/import/git/gcc/gcc/main.c:36

(gdb)


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-09 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #23 from H.J. Lu hjl.tools at gmail dot com 2013-01-09 22:51:36 
UTC ---

The old BLOCK came from



(gdb) bt

#0  remap_block (block=0x7fffd690, id=0x7fffd840) at

/export/gnu/import/git/gcc/gcc/tree-inline.c:624

#1  0x009fe52a in remap_blocks (block=0x71393d20,

id=0x7fffd840)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:645

#2  0x009fe586 in remap_blocks (block=0x71385370,

id=0x7fffd840)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:648

#3  0x009fe586 in remap_blocks (block=0x71385320,

id=0x7fffd840)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:648

---Type return to continue, or q return to quit---

#4  0x009fe586 in remap_blocks (block=0x71385280,

id=0x7fffd840)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:648

#5  0x009fe586 in remap_blocks (block=0x713851e0,

id=0x7fffd840)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:648

#6  0x00a0bc63 in tree_function_versioning (old_decl=0x7fffec94b400,

new_decl=0x7fffe9105000, tree_map=0x0, 

update_clones=true, args_to_skip=0x0, skip_return=false,

blocks_to_copy=0x0, new_entry=0x0)

at /export/gnu/import/git/gcc/gcc/tree-inline.c:5225

---Type return to continue, or q return to quit---

#7  0x007d2d05 in save_inline_function_body (node=0x71753818)

at /export/gnu/import/git/gcc/gcc/ipa-inline-transform.c:354

#8  0x007d2ec6 in inline_transform (node=0x71753818) at

/export/gnu/import/git/gcc/gcc/ipa-inline-transform.c:411

#9  0x008adbe3 in execute_one_ipa_transform_pass (node=0x71753818,

ipa_pass=0x16cfc80 pass_ipa_inline)

at /export/gnu/import/git/gcc/gcc/passes.c:2177

#10 0x008add31 in execute_all_ipa_transforms () at

/export/gnu/import/git/gcc/gcc/passes.c:2213

#11 0x005da348 in expand_function (node=0x71753818) at

/export/gnu/import/git/gcc/gcc/cgraphunit.c:1634

---Type return to continue, or q return to quit---

#12 0x005da821 in expand_all_functions () at

/export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

#13 0x005db2ab in compile () at

/export/gnu/import/git/gcc/gcc/cgraphunit.c:2043

#14 0x0053c60a in lto_main () at

/export/gnu/import/git/gcc/gcc/lto/lto.c:3390

#15 0x00999401 in compile_file () at

/export/gnu/import/git/gcc/gcc/toplev.c:545

#16 0x0099b3e4 in do_compile () at

/export/gnu/import/git/gcc/gcc/toplev.c:1878

#17 0x0099b54f in toplev_main (argc=28, argv=0x7fffdc78) at

/export/gnu/import/git/gcc/gcc/toplev.c:1954

#18 0x00fff958 in main (argc=28, argv=0x7fffdc78) at

/export/gnu/import/git/gcc/gcc/main.c:36

(gdb) p id-block

$90 = (tree) 0x0


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-08 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 2013-01-08 
10:17:16 UTC ---

(In reply to comment #11)

 (In reply to comment #9)

  Eh.  Diego, how does GTY((user)) work here?  It smells like a bug in vec.h

  to me.

  

  /* Garbage collection support for vecT, A, vl_embed.  */

  

  templatetypename T

  void

  gt_ggc_mx (vecT, va_gc *v)

  {

extern void gt_ggc_mx (T );

for (unsigned i = 0; i  v-length (); i++)

  gt_ggc_mx ((*v)[i]);

  }

  

  doesn't it need to mark the vec itself?  Maybe automatic registration of

  roots (this is a GC root) does not work with GTY((user))?

 

 No.  The root is/should be marked by the code calling gt_ggc_mx.  gengtype 
 will

 generate code like:

 

   if (ggc_test_and_set_mark (x))

 {

   gt_ggc_mx (x);

 }

 

 ggc_test_and_set_mark() is the one that marks the root.  Has gengtype 
 generated

 a function for this global?  It should be something like this

 

 void

 gt_ggc_mx_vec_mangled_type_name (void *x_p)

 {

   vectype_name,va_gc * const x = (vectype_name,va_gc *)x_p;

   if (ggc_test_and_set_mark (x))

 {

   gt_ggc_mx (x);

 }

 }



There is



EXPORTED_CONST struct ggc_root_tab gt_ggc_r_gtype_desc_c[] = {

...

  {

lto_global_var_decls,

1,

sizeof (lto_global_var_decls),

gt_ggc_mx_vec_tree_va_gc_,

gt_pch_nx_vec_tree_va_gc_

  },



in gtype-desc.c, which looks like



void

gt_ggc_mx_vec_tree_va_gc_ (void *x_p)

{

  vectree,va_gc * const x = (vectree,va_gc *)x_p;

  if (ggc_test_and_set_mark (x))

{

  gt_ggc_mx (x);

}

}



with



/* If EXPR is not NULL and previously unmarked, mark it and evaluate

   to true.  Otherwise evaluate to false.  */

#define ggc_test_and_set_mark(EXPR) \

  ((EXPR) != NULL  ((void *) (EXPR)) != (void *) 1  ! ggc_set_mark (EXPR))



this indeed looks correct to me given vec.h's



templatetypename T

void

gt_ggc_mx (vecT, va_gc *v)

{

  extern void gt_ggc_mx (T );

  for (unsigned i = 0; i  v-length (); i++)

gt_ggc_mx ((*v)[i]);

}



and the generated(?)



void

gt_ggc_mx (union tree_node * x)

{

  if (x)

gt_ggc_mx_lang_tree_node ((void *) x);

}



So I'm still not sure what HJ means with it's collected.  GC roots are

never collected.  HJ, should your patch fix anything?  What do you think

the bug is?


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-08 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #16 from H.J. Lu hjl.tools at gmail dot com 2013-01-08 17:12:57 
UTC ---

(In reply to comment #15)

 So I'm still not sure what HJ means with it's collected.  GC roots are

 never collected.  HJ, should your patch fix anything?  What do you think

 the bug is?



My patch is an optimization, not a fix.


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-08 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #17 from H.J. Lu hjl.tools at gmail dot com 2013-01-09 00:22:18 
UTC ---

gimple_location is duplicated by:



#1  0x00751f32 in gimple_copy (stmt=0x7fffe8d75a00)

at /export/gnu/import/git/gcc/gcc/gimple.c:2205

#2  0x009c960d in gimple_duplicate_bb (bb=0x7fffe8d768f0)

at /export/gnu/import/git/gcc/gcc/tree-cfg.c:5397

#3  0x005b27a5 in duplicate_block (bb=0x7fffe8d768f0, 

e=0x7fffe8d793f0, after=0x7fffe8d76888)

at /export/gnu/import/git/gcc/gcc/cfghooks.c:1012

#4  0x0099c511 in tail_duplicate ()

at /export/gnu/import/git/gcc/gcc/tracer.c:323

#5  0x0099c765 in tracer ()

at /export/gnu/import/git/gcc/gcc/tracer.c:380

#6  0x008ae0e6 in execute_one_pass (pass=0x16d18a0 pass_tracer)

at /export/gnu/import/git/gcc/gcc/passes.c:2335

#7  0x008ae2da in execute_pass_list (pass=0x16d18a0 pass_tracer)

at /export/gnu/import/git/gcc/gcc/passes.c:2383

#8  0x008ae30b in execute_pass_list (

pass=0x16d07e0 pass_all_optimizations)

at /export/gnu/import/git/gcc/gcc/passes.c:2384

#9  0x005da366 in expand_function (node=0x717536f0)

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

#10 0x005da821 in expand_all_functions ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

(gdb) p copy

$176 = (gimple) 0x7fffe8e0a320

(gdb) 



Later, the original location is removed:



#0  remove_unused_locals ()

at /export/gnu/import/git/gcc/gcc/tree-ssa-live.c:793

#1  0x008ad5cb in execute_function_todo (data=0x8800)

at /export/gnu/import/git/gcc/gcc/passes.c:1952

#2  0x008ac965 in do_per_function (

callback=0x8ad4ae execute_function_todo(void*), data=0x8800)

at /export/gnu/import/git/gcc/gcc/passes.c:1703

#3  0x008ad765 in execute_todo (flags=34816)

at /export/gnu/import/git/gcc/gcc/passes.c:2001

#4  0x008ae175 in execute_one_pass (

pass=0x16d3220 pass_cleanup_cfg_post_optimizing)

at /export/gnu/import/git/gcc/gcc/passes.c:2349

#5  0x008ae2da in execute_pass_list (

pass=0x16d3220 pass_cleanup_cfg_post_optimizing)

at /export/gnu/import/git/gcc/gcc/passes.c:2383

#6  0x005da366 in expand_function (node=0x717536f0)

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

#7  0x005da821 in expand_all_functions ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745



and freed.  Then we copy the freed gimple_location:



#0  expand_gimple_stmt_1 (stmt=0x7fffe8e0a320)

at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2202

#1  0x005a7786 in expand_gimple_stmt (stmt=0x7fffe8e0a320)

at /export/gnu/import/git/gcc/gcc/cfgexpand.c:2305

#2  0x005ad975 in expand_gimple_basic_block (bb=0x7fffe8d76888, 

disable_tail_calls=false)

at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4084

#3  0x005af426 in gimple_expand_cfg ()

at /export/gnu/import/git/gcc/gcc/cfgexpand.c:4603

#4  0x008ae0e6 in execute_one_pass (pass=0x16ce300 pass_expand)

at /export/gnu/import/git/gcc/gcc/passes.c:2335

#5  0x008ae2da in execute_pass_list (pass=0x16ce300 pass_expand)

at /export/gnu/import/git/gcc/gcc/passes.c:2383

#6  0x005da366 in expand_function (node=0x717536f0)

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1641

#7  0x005da821 in expand_all_functions ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1745

#8  0x005db2ab in compile ()

at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2043

#9  0x0053c60a in lto_main ()

at /export/gnu/import/git/gcc/gcc/lto/lto.c:3390

#10 0x00999401 in compile_file ()

at /export/gnu/import/git/gcc/gcc/toplev.c:545


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-07 Thread rguenth at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



   Priority|P3  |P1

Summary|Bad memory access with  |[4.8 Regression] Bad memory

   |profiledbootstrap and LTO   |access with

   ||profiledbootstrap and LTO



--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-01-07 
16:02:38 UTC ---

vec + GC related regression.


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-07 Thread dnovillo at gcc dot gnu.org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #11 from Diego Novillo dnovillo at gcc dot gnu.org 2013-01-07 
17:54:14 UTC ---

(In reply to comment #9)

 Eh.  Diego, how does GTY((user)) work here?  It smells like a bug in vec.h

 to me.

 

 /* Garbage collection support for vecT, A, vl_embed.  */

 

 templatetypename T

 void

 gt_ggc_mx (vecT, va_gc *v)

 {

   extern void gt_ggc_mx (T );

   for (unsigned i = 0; i  v-length (); i++)

 gt_ggc_mx ((*v)[i]);

 }

 

 doesn't it need to mark the vec itself?  Maybe automatic registration of

 roots (this is a GC root) does not work with GTY((user))?



No.  The root is/should be marked by the code calling gt_ggc_mx.  gengtype will

generate code like:



  if (ggc_test_and_set_mark (x))

{

  gt_ggc_mx (x);

}



ggc_test_and_set_mark() is the one that marks the root.  Has gengtype generated

a function for this global?  It should be something like this



void

gt_ggc_mx_vec_mangled_type_name (void *x_p)

{

  vectype_name,va_gc * const x = (vectype_name,va_gc *)x_p;

  if (ggc_test_and_set_mark (x))

{

  gt_ggc_mx (x);

}

}


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-07 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2013-01-07 22:13:33 
UTC ---

(In reply to comment #4)

 Created attachment 29085 [details]

 A patch to move lto_global_var_decls to lto/lto.c

 

 With this patch, I got

 

 lto1: internal compiler error: Segmentation fault

 0x997fc5 crash_signal

 /export/gnu/import/git/gcc/gcc/toplev.c:334

 0x545095 ggc_get_size(void const*)



This patch misses:



diff --cc gcc/lto/config-lang.in

index 90235b0,90235b0..839d359

--- a/gcc/lto/config-lang.in

+++ b/gcc/lto/config-lang.in

@@@ -22,7 -22,7 +22,7 @@@ language=lto

  compilers=lto1\$(exeext)

  stagestuff=lto1\$(exeext)



--gtfiles=\$(srcdir)/lto/lto-tree.h \$(srcdir)/lto/lto-lang.c

\$(srcdir)/lto/lt

o.c

++gtfiles=\$(srcdir)/lto/lto-tree.h \$(srcdir)/lto/lto-lang.c

\$(srcdir)/lto/lt

o.c \$(srcdir)/lto/lto.h



  # LTO is a special front end.  From a user's perspective it is not

  # really a language, but a middle end feature.  However, the GIMPLE


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-07 Thread hjl.tools at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792

--- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2013-01-07 23:30:15 
UTC ---
For the testcase at

https://sites.google.com/site/x32abi/documents/jc1.ltrans23.o.xz?attredirects=0d=1

[hjl@gnu-6 gcc]$ ./lto1 -quiet -dumpdir ./ -dumpbase jc1.ltrans23
-mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip
jc1.ltrans23.ltrans.o -g -O2 -Wextra -Wpedantic -version -frandom-seed=1
-fprofile-use -fno-exceptions -fasynchronous-unwind-tables -fno-common -fltrans
~/tmp/jc1.ltrans23.o -o x.s
GNU GIMPLE (GCC) version 4.8.0 20130107 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.8.0 20130107 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
In file included from :1642:0:
/export/gnu/import/git/gcc/gcc/recog.c: In function ‘peep2_find_free_register’:
/export/gnu/import/git/gcc/gcc/recog.c:3074:0: internal compiler error:
Segmentation fault
 peep2_find_free_register (int from, int to, const char *class_str,
 ^
0x998b6d crash_signal
/export/gnu/import/git/gcc/gcc/toplev.c:334
0x544540 lookup_page_table_entry
/export/gnu/import/git/gcc/gcc/ggc-page.c:594
0x5455f5 ggc_set_mark(void const*)
/export/gnu/import/git/gcc/gcc/ggc-page.c:1477
0x79e602 gt_ggc_mx_dw_loc_descr_struct(void*)
/export/build/gnu/gcc/build-x86_64-linux/gcc/gtype-desc.c:390
0x79e635 gt_ggc_mx_dw_loc_descr_struct(void*)
/export/build/gnu/gcc/build-x86_64-linux/gcc/gtype-desc.c:392
0x65d538 gt_ggc_mx_dw_loc_list_struct(void*)
./gt-dwarf2out.h:371
0x65ced2 gt_ggc_mx(dw_attr_struct)
./gt-dwarf2out.h:181
0x65ce3c gt_ggc_mx_vec_dw_attr_node_va_gc_(void*)
./gt-dwarf2out.h:164
0x65d62b gt_ggc_mx_die_struct(void*)
./gt-dwarf2out.h:398
0x65d665 gt_ggc_mx_die_struct(void*)
./gt-dwarf2out.h:400
0x65d665 gt_ggc_mx_die_struct(void*)
./gt-dwarf2out.h:400
0x525697 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:369
0x523a2d gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:55
0x5255f4 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:357
0x523a2d gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:55
0x5255d7 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:356
0x52562e gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:359
0x5256d9 gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:375
0x52559d gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:354
0x52559d gt_ggc_mx_lang_tree_node(void*)
./gtype-lto.h:354
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[hjl@gnu-6 gcc]$


[Bug bootstrap/55792] [4.8 Regression] Bad memory access with profiledbootstrap and LTO

2013-01-07 Thread hjl.tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792



--- Comment #14 from H.J. Lu hjl.tools at gmail dot com 2013-01-08 01:19:29 
UTC ---

(In reply to comment #13)

 For the testcase at

 

 https://sites.google.com/site/x32abi/documents/jc1.ltrans23.o.xz?attredirects=0d=1

 

 [hjl@gnu-6 gcc]$ ./lto1 -quiet -dumpdir ./ -dumpbase jc1.ltrans23

 -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip

 jc1.ltrans23.ltrans.o -g -O2 -Wextra -Wpedantic -version -frandom-seed=1

 -fprofile-use -fno-exceptions -fasynchronous-unwind-tables -fno-common 
 -fltrans

 ~/tmp/jc1.ltrans23.o -o x.s



Remove -fprofile-use or add -fno-tracer fix ICE.