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 <gch...@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 >
