This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Line 0 Hack??
- From: Gabriel Charette <gchare at google dot com>
- To: steven at gcc dot gnu dot org, Tom Tromey <tromey at redhat dot com>
- Cc: Diego Novillo <dnovillo at google dot com>, Lawrence Crowl <crowl at google dot com>, Collin Winter <collinwinter at google dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 1 Aug 2011 20:17:20 -0700
- Subject: Re: Line 0 Hack??
- References: <CAJTZ7LL9JW0S_tDxZ80DvNcPQSD_+PRD4yQ4HkykLqjJOLbY7g@mail.gmail.com> <CAJTZ7LJ1Ad0h-kquEv09HNKVmaOB4JL9+BMRJbr7J=GuyLFo5Q@mail.gmail.com>
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
>