[Bug target/46655] invalid '.line 0' directive emitted with -g

["hainque at adacore dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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