http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451
--- Comment #4 from Cary Coutant <ccoutant at gcc dot gnu.org> ---
The problem is a lexical block in main() that appears to be getting split by
-freorder-blocks-and-partition, but when debug info is emitted during
rest_of_handle_final(), this particular lexical block still appears to be a
single block -- BLOCK_FRAGMENT_CHAIN is NULL, so the DWARF output code decides
that it can emit a DW_AT_low_pc/high_pc pair instead of a DW_AT_ranges. The
DW_AT_high_pc is now being output relative to DW_AT_low_pc, so we see an
assembly expression .LBE14 - .LBB14, which are labels attached to the block
start and block end, and should be in the same section.
Here's the block:
(gdb) p stmt
$1 = (tree) 0x7ffff5f4c4b0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
<block 0x7ffff5f4c4b0 asm_written used
vars <var_decl 0x7ffff608bc78 e
type <reference_type 0x7ffff609b930 type <record_type 0x7ffff608e9d8
MyException>
sizes-gimplified unsigned DI
size <integer_cst 0x7ffff5f24dc0 constant 64>
unit size <integer_cst 0x7ffff5f24de0 constant 8>
align 64 symtab 0 alias set -1 canonical type 0x7ffff609b930>
readonly tree_1 tree_3 unsigned decl_5 DI file pr49115.C line 21 col 25
size <integer_cst 0x7ffff5f24dc0 64> unit size <integer_cst 0x7ffff5f24de0 8>
align 64 context <function_decl 0x7ffff6096f00 main>>
supercontext <block 0x7ffff60c00f0 asm_written used
vars <var_decl 0x7ffff608bb48 data type <record_type 0x7ffff608ec78
Data>
used tree_1 tree_3 decl_5 SI file pr49115.C line 18 col 8
size <integer_cst 0x7ffff5f42140 constant 32>
unit size <integer_cst 0x7ffff5f42160 constant 4>
align 128 context <function_decl 0x7ffff6096f00 main>
(reg/v:SI 64 [ data ])>
supercontext <block 0x7ffff5f4c550 asm_written used supercontext
<function_decl 0x7ffff6096f00 main>
subblocks <block 0x7ffff5f4c500 asm_written used vars <var_decl
0x7ffff608bb48 data> supercontext <block 0x7ffff5f4c550> subblocks <block
0x7ffff5f4c4b0> chain <block 0x7ffff60c00f0>>>>>
(gdb) p stmt->block
$2 = {base = {code = BLOCK, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0,
volatile_flag = 0, readonly_flag = 0, asm_written_flag = 1, nowarning_flag
= 0, visited = 0,
used_flag = 1, nothrow_flag = 0, static_flag = 0, public_flag = 0,
private_flag = 0,
protected_flag = 0, deprecated_flag = 0, default_def_flag = 0, u = {bits =
{lang_flag_0 = 0,
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0,
lang_flag_5 = 0,
lang_flag_6 = 0, saturating_flag = 0, unsigned_flag = 0, packed_flag =
0, user_align = 0,
nameless_flag = 1, spare0 = 0, spare1 = 0, address_space = 0}, length =
2048,
version = 2048}}, chain = 0x0, abstract_flag = 0, block_num = 14, locus =
0,
vars = 0x7ffff608bc78, nonlocalized_vars = 0x0, subblocks = 0x0, supercontext
= 0x7ffff60c00f0,
abstract_origin = 0x0, fragment_origin = 0x0, fragment_chain = 0x0}
Here's the fragment of assembly code between .LBB14 and .LBE14:
.LBB14:
# pr49115.C:21
.loc 1 21 0
call __cxa_begin_catch
.LVL7:
call __cxa_end_catch
.LVL8:
.p2align 4,,5
# SUCC: 3 [100.0%] count:1
jmp .L15
.cfi_endproc
.section .text.unlikely
.cfi_startproc
.cfi_personality 0x3,__gxx_personality_v0
.cfi_lsda 0x3,.LLSDAC4
# BLOCK 6 freq:5000 seq:4
# PRED: 4 [50.0%] (CROSSING,CAN_FALLTHRU)
.L14:
.cfi_def_cfa_offset 16
.p2align 4,,8
.LEHB1:
# SUCC:
call _Unwind_Resume
.LEHE1:
.LVL9:
.LBE14:
.LBE15:
.cfi_endproc
You can see that the block from .LBB14 to .LBE14 has been split across two
sections. In order for dwarf2out to generate the proper debug info,
BLOCK_FRAGMENT_CHAIN(stmt) needs to be non-NULL. I'm not sure why that's not
happening when the block is split.
