Re: Line 0 Hack??

Re: Line 0 Hack??

[Gabriel Charette]

Re-sending as plain text for gcc@gcc.gnu.org ...

----------------------------

Hi,

I have a question about the line 0 hack on line 13232 of gcc/cp/decl.c
(or just text search for "Hack", it's the only place it's found in
that file...).

From my revision history, Steven introduced this in 2005, and Tom
modified it in 2007 (probably when modifying the linemap).

The problem is that this very call to get the source_location of line
0 creates a NEW linemap entry in the line table, AFTER all of the
LC_LEAVE have taken place (i.e. we were done parsing and now add a new
linemap to the line_table)...

And hence, we finish the parsing with line_table->depth == 1.

In particular, I am building linemap serialization for pre-parsed
headers, and added what I think to be a fair gcc_assert that when we
serialize the line_table, it's depth should be 0. However, if we
happen to have "main" in the header (this is when we get in this block
in decl.c from my understanding as DECL_MAIN_P is then true), a new
linemap is added at the end of the line table in the header after the
LC_LEAVE... when merging this in the middle of a C file upon
deserializing, this entry makes no sense, but I can't just ignore it
either as a source_location has been handed off for it...

My question is, what is this "special line 0" is this just a hack for
this particular situation or is "line 0" a much more important concept
I can't mess around with?

I could potentially hack around it, but hacking around a hack can only
make things worst in the long run..

I'm not familiar with the "middle end warning" referred to in the
comment in decl.c, could we potentially once and for all get rid of
this hack?

Best,
Gabriel

Re: Line 0 Hack??

[Gabriel Charette]

I have removed the hack and the test output is identical to the clean
build test output.

See issue4835047 for the patch.

Gabriel

On Mon, Aug 1, 2011 at 2:56 PM, Gabriel Charette <gchare@google.com> wrote:
> Re-sending as plain text for gcc@gcc.gnu.org ...
>
> ----------------------------
>
> Hi,
>
> I have a question about the line 0 hack on line 13232 of gcc/cp/decl.c
> (or just text search for "Hack", it's the only place it's found in
> that file...).
>
> From my revision history, Steven introduced this in 2005, and Tom
> modified it in 2007 (probably when modifying the linemap).
>
> The problem is that this very call to get the source_location of line
> 0 creates a NEW linemap entry in the line table, AFTER all of the
> LC_LEAVE have taken place (i.e. we were done parsing and now add a new
> linemap to the line_table)...
>
> And hence, we finish the parsing with line_table->depth == 1.
>
> In particular, I am building linemap serialization for pre-parsed
> headers, and added what I think to be a fair gcc_assert that when we
> serialize the line_table, it's depth should be 0. However, if we
> happen to have "main" in the header (this is when we get in this block
> in decl.c from my understanding as DECL_MAIN_P is then true), a new
> linemap is added at the end of the line table in the header after the
> LC_LEAVE... when merging this in the middle of a C file upon
> deserializing, this entry makes no sense, but I can't just ignore it
> either as a source_location has been handed off for it...
>
> My question is, what is this "special line 0" is this just a hack for
> this particular situation or is "line 0" a much more important concept
> I can't mess around with?
>
> I could potentially hack around it, but hacking around a hack can only
> make things worst in the long run..
>
> I'm not familiar with the "middle end warning" referred to in the
> comment in decl.c, could we potentially once and for all get rid of
> this hack?
>
> Best,
> Gabriel
>