[Bug lto/56515] [4.8 Regression] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 09:20:36 UTC --- Author: rguenth Date: Tue Mar 5 09:20:30 2013 New Revision: 196452 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196452 Log: 2013-03-05 Richard Biener rguent...@suse.de PR lto/56515 * tree-inline.c (remap_blocks_to_null): New function. (expand_call_inline): When expanding a call stmt without an associated block inline remap all callee blocks to NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c
[Bug lto/56515] [4.8 Regression] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-03-05 09:21:10 UTC --- Fixed.
[Bug lto/56515] [4.8 Regression] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-04 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Summary|location references block |[4.8 Regression] location |not in block tree, |references block not in |verify_gimple failed (LTO + |block tree, verify_gimple |profile)|failed (LTO + profile) Ever Confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 11:03:04 UTC --- Confirmed. I'll try to nail it down.
[Bug lto/56515] [4.8 Regression] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-04 12:10:32 UTC --- We inline __gcov_indirect_call_profiler: 2 foo.o 4 211 1fa7ccac167ed480 PREVAILING_DEF foo 218 1fa7ccac167ed480 RESOLVED_EXEC __gcov_merge_add 220 1fa7ccac167ed480 RESOLVED_IR __gcov_indirect_call_profiler 229 1fa7ccac167ed480 RESOLVED_EXEC __gcov_init bar.o 2 165 fdbab47f5593e985 PREVAILING_DEF_IRONLY __gcov_indirect_call_profiler 186 fdbab47f5593e985 PREVAILING_DEF_IRONLY bar We build the function decls via build_fn_decl which ends up using input_location of the first random function we are processing. But that doesn't seem to be the issue after all ... The issue is that we do in expand_call_inline: /* Build a block containing code to initialize the arguments, the actual inline expansion of the body, and a label for the return statements within the function to jump to. The type of the statement expression is the return type of the function call. */ id-block = make_node (BLOCK); BLOCK_ABSTRACT_ORIGIN (id-block) = fn; BLOCK_SOURCE_LOCATION (id-block) = input_location; if (gimple_block (stmt)) prepend_lexical_block (gimple_block (stmt), id-block); that is, we only link the copied BLOCK tree into the caller BLOCK tree if the call stmt had an associated BLOCK. Which isn't the case for the calls created by the middle-end (profile instrumentation in this case).
[Bug lto/56515] [4.8 Regression] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz 2013-03-04 16:06:25 UTC --- We build the function decls via build_fn_decl which ends up using input_location of the first random function we are processing. But that doesn't seem to be the issue after all ... The issue is that we do in expand_call_inline: /* Build a block containing code to initialize the arguments, the actual inline expansion of the body, and a label for the return statements within the function to jump to. The type of the statement expression is the return type of the function call. */ id-block = make_node (BLOCK); BLOCK_ABSTRACT_ORIGIN (id-block) = fn; BLOCK_SOURCE_LOCATION (id-block) = input_location; if (gimple_block (stmt)) prepend_lexical_block (gimple_block (stmt), id-block); that is, we only link the copied BLOCK tree into the caller BLOCK tree if the call stmt had an associated BLOCK. Which isn't the case for the calls created by the middle-end (profile instrumentation in this case). Hmm, yeah, thre are few cases where we sort of assume that each call has a block. I wonder what should we do here, just prepend the block for the outermost block of the caller function then? In general however LTO of libgcov is not supposed to work same way as libgcc or glibc does not work. We can't LTO yet any functions where middle-end invent calls post LTO streaming. I blieve we still do so for libgcov for fork calls. Honza
