From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27044 invoked by alias); 23 Aug 2011 18:59:18 -0000 Received: (qmail 27036 invoked by uid 22791); 23 Aug 2011 18:59:17 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Aug 2011 18:59:01 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7NIwUFD004301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2011 14:58:31 -0400 Received: from localhost (ovpn-113-51.phx2.redhat.com [10.3.113.51]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7NIwS8b003988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2011 14:58:29 -0400 Received: by localhost (Postfix, from userid 500) id 6CF6829C057; Tue, 23 Aug 2011 20:58:27 +0200 (CEST) From: Dodji Seketeli To: Alexandre Oliva Cc: gcc-patches@gcc.gnu.org, tromey@redhat.com, gdr@integrable-solutions.net, joseph@codesourcery.com, burnus@net-b.de, charlet@act-europe.fr, paolo@gnu.org, jason@redhat.com Subject: Re: [PATCH 4/7] Support -fdebug-cpp option References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <1902ac92ebf0b213bfafdeb31edaac8812b5399b.1310824121.git.dodji@redhat.com> X-URL: http://www.redhat.com Date: Tue, 23 Aug 2011 19:52:00 -0000 In-Reply-To: (Alexandre Oliva's message of "Sun, 21 Aug 2011 04:51:54 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg01935.txt.bz2 Alexandre Oliva writes: > On Jul 16, 2011, Dodji Seketeli wrote: > >> This patch adds -fdebug-cpp option. When used with -E this dumps the >> relevant macro map before every single token. This clutters the output >> a lot but has proved to be invaluable in tracking some bugs during the >> development of the virtual location support. > > Any way to read that back in while compiling a preprocessed file, so > that ccache et al can use this flag to get the same location information > that would have been gotten without separate preprocessing? Jakub Jelinek writes: > > For ccache and friends I think it would be better to have a preprocessing > mode that would output all lines as is (i.e. no macro replacement), except > for processing #include/#include_next directives. Would that be enough for, say, when people submit bug reports to GCC? I think it would but maybe I am missing some corner cases. Tom Tromey writes: >>>>>> "Jakub" == Jakub Jelinek writes: > > Jakub> For ccache and friends I think it would be better to have a > Jakub> preprocessing mode that would output all lines as is (i.e. no > Jakub> macro replacement), except for processing #include/#include_next > Jakub> directives. > > That exists -- -fdirectives-only. > > Tom Jakub Jelinek writes: > On Mon, Aug 22, 2011 at 08:16:45AM -0600, Tom Tromey wrote: >> >>>>> "Jakub" == Jakub Jelinek writes: >> >> Jakub> For ccache and friends I think it would be better to have a >> Jakub> preprocessing mode that would output all lines as is (i.e. no >> Jakub> macro replacement), except for processing #include/#include_next >> Jakub> directives. >> >> That exists -- -fdirectives-only. > > It isn't exactly what would be needed, as e.g. \\\n are removed from > from #defines and thus they get different location of the tokens. Would it be acceptable to just change the output of -fdirective to fit? Or are we bound to not breaking existing consumers? > > BTW, I guess we should do something about parsing such an output, > we emit e.g. > # 1 "" > # 1 "" > #define __STDC__ 1 > #define __STDC_HOSTED__ 1 > #define __GNUC__ 4 > #define __GNUC_MINOR__ 6 > #define __GNUC_PATCHLEVEL__ 0 > ... > > For we really should assume line 0 for all the defines > in that "file". Right now BUILTIN_LOCATION is defined to 1 at least the C/C++ FEs. Are you saying defines should have UNKNOWN_LOCATION (which is 0) instead? OTOH, c_builtin_function already sets the location of c builtins to UNKNOWN_LOCATION. Which makes me wonder what BUILTIN_LOCATION is actually good for then. :-) -- Dodji