https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90496
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Richard Biener from comment #2) > Confirmed with GCC 8: > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000001ce24bb in unix_lbasename (name=0x0) > at /space/rguenther/src/svn/gcc-8-branch/libiberty/lbasename.c:53 > 53 for (base = name; *name; name++) > (gdb) bt > #0 0x0000000001ce24bb in unix_lbasename (name=0x0) > at /space/rguenther/src/svn/gcc-8-branch/libiberty/lbasename.c:53 > #1 0x0000000001ce2561 in lbasename (name=0x0) > at /space/rguenther/src/svn/gcc-8-branch/libiberty/lbasename.c:82 > #2 0x0000000000ef0468 in output_stack_usage () > at /space/rguenther/src/svn/gcc-8-branch/gcc/toplev.c:1024 > #3 0x0000000000aef817 in rest_of_handle_thread_prologue_and_epilogue () > at /space/rguenther/src/svn/gcc-8-branch/gcc/function.c:6546 > #4 0x0000000000aef865 in (anonymous > namespace)::pass_thread_prologue_and_epilogue::execute (this=0x2a7a6d0) > at /space/rguenther/src/svn/gcc-8-branch/gcc/function.c:6576 > > where we seem to not consider that a location might have a NULL loc.file: > > (gdb) p debug_tree (current_function_decl) > <function_decl 0x7ffff669cc00 _GLOBAL__sub_I_00099_0_main > type <function_type 0x7ffff689ac78 > type <void_type 0x7ffff688ef18 void VOID > align:8 warn_if_not_align:0 symtab:0 alias-set -1 > structural-equality > pointer_to_this <pointer_type 0x7ffff68950a8>> > QI > size <integer_cst 0x7ffff687acd8 constant 8> > unit-size <integer_cst 0x7ffff687acf0 constant 1> > align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality > arg-types <tree_list 0x7ffff688daa0 value <void_type 0x7ffff688ef18 > void>> > pointer_to_this <pointer_type 0x7ffff6698348>> > asm_written used static ignored uninlinable QI (null):0:0 align:8 > warn_if_not_align:0 initial <block 0x7ffff66a2060> > result <result_decl 0x7ffff6884258 D.4688 type <void_type 0x7ffff688ef18 > void> > VOID (null):0:0 > align:8 warn_if_not_align:0 context <function_decl 0x7ffff669cc00 > _GLOBAL__sub_I_00099_0_main>> > struct-function 0x7ffff66a3160> > > (gdb) p current_function_decl->decl_minimal.locus > $5 = 0 > (gdb) p current_function_decl->decl_common.artificial_flag > $6 = 1 > > it probably doesn't make sense to print stack usage for compiler-generated > functions? Or at least UNKNOWN_LOCATION should be handled better. Or I'm suggesting to print '(artificial)' as location of the function. One may be theoretically interested in the static [cd]tor stack usage. > > Eric? > > Probably not really LTO specific.
