From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22102 invoked by alias); 1 Aug 2011 21:56:22 -0000 Received: (qmail 22090 invoked by uid 22791); 1 Aug 2011 21:56:21 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Aug 2011 21:56:04 +0000 Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p71Lu3Ls007597 for ; Mon, 1 Aug 2011 14:56:03 -0700 Received: from gwj16 (gwj16.prod.google.com [10.200.10.16]) by hpaq3.eem.corp.google.com with ESMTP id p71Lu1GT018470 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 1 Aug 2011 14:56:02 -0700 Received: by gwj16 with SMTP id 16so5287997gwj.23 for ; Mon, 01 Aug 2011 14:56:01 -0700 (PDT) Received: by 10.101.44.4 with SMTP id w4mr1652840anj.108.1312235760901; Mon, 01 Aug 2011 14:56:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.44.4 with SMTP id w4mr1652835anj.108.1312235760768; Mon, 01 Aug 2011 14:56:00 -0700 (PDT) Received: by 10.100.191.19 with HTTP; Mon, 1 Aug 2011 14:56:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 01 Aug 2011 21:56:00 -0000 Message-ID: Subject: Re: Line 0 Hack?? From: Gabriel Charette To: steven@gcc.gnu.org, Tom Tromey Cc: Diego Novillo , Lawrence Crowl , Collin Winter , gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg00027.txt.bz2 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...). =46rom 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 =3D=3D 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"=A0referred=A0to in the comment in decl.c, could we potentially once and for all get rid of this hack? Best, Gabriel