http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
--- Comment #13 from hainque at adacore dot com <hainque at adacore dot com> 2010-11-30 17:49:20 UTC --- dje at gcc dot gnu.org wrote: > Did something change in GCC that now generates line 0 debug > information? For Ada cases, we had mixups with BUILTINS_LOCATION. The testcase below triggered it for entirely different reasons in C with at least 4.5, and supposedly on. While there are multiple factors at play, I think one triggering piece was a change issued from http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00649.html In particular: --- c-parser.c (revision 140120) +++ c-parser.c (working copy) @@ -1301,9 +1301,9 @@ c_parser_declaration_or_fndef (c_parser while (c_parser_next_token_is_not (parser, CPP_EOF) && c_parser_next_token_is_not (parser, CPP_OPEN_BRACE)) c_parser_declaration_or_fndef (parser, false, false, true, false); - DECL_SOURCE_LOCATION (current_function_decl) - = c_parser_peek_token (parser)->location; store_parm_decls (); + DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus + = c_parser_peek_token (parser)->location; for "__frame_state_for" at line 9 in the example below, we used to have <function_decl 0x7ffff7f4d3c0 __frame_state_for public static SI file /home/hainque/tmp/t.c line 10 col 1 ^^^^^^^ and we now have line 9 instead. Later on, code get that loc assigned, which translates as .line 0 now (used to be .line 1). -- 1 const int NREGS = 20; 2 3 typedef struct frame_state 4 { 5 void *eh_ptr; 6 char saved[20]; 7 } frame_state; 8 9 void __frame_state_for (struct frame_state *state_in) 10 { 11 int reg; 12 13 for (reg = 0; reg < NREGS; reg++) 14 state_in->saved[reg] = 0; 15 } 16