From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31322 invoked by alias); 10 Dec 2010 16:45:54 -0000 Received: (qmail 31311 invoked by uid 22791); 10 Dec 2010 16:45:52 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Fri, 10 Dec 2010 16:45:47 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBAGjdfw018817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Dec 2010 11:45:39 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oBAGjcKH016719; Fri, 10 Dec 2010 11:45:38 -0500 Received: from [10.3.113.58] (ovpn-113-58.phx2.redhat.com [10.3.113.58]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id oBAGjaU8002095; Fri, 10 Dec 2010 11:45:37 -0500 Message-ID: <4D025930.6020000@redhat.com> Date: Fri, 10 Dec 2010 16:59:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.6 MIME-Version: 1.0 To: Dodji Seketeli CC: gcc-patches@gcc.gnu.org, tromey@redhat.com, joseph@codesourcery.com, gdr@integrable-solutions.net, lopezibanez@gmail.com Subject: Re: [PATCH 0/6] Tracking locations of tokens resulting from macro expansion References: <1291979498-1604-1-git-send-email-dodji@redhat.com> In-Reply-To: <1291979498-1604-1-git-send-email-dodji@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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: 2010-12/txt/msg00894.txt.bz2 On 12/10/10 04:11, Dodji Seketeli wrote: > The problem is tokens '1.0', '<<' and '1' all have their location set > to {line 11, column 3} ({11, 3} for short). That actually is the > location of the expansion point of the MULT macro. That's is an > interesting observation -- in the current incarnation of GCC the > location of each tokens resulting from a macro expansion is set to the > location of the expansion point of the macro. Presumably you meant {13, 3}, right? > Several obversations can be made in that hypothetical example. > > - The location mentioned in the error message > > test.c:5:14: error: invalid operands to binary<< (have ‘double’ and ‘int’) > > is the spelling location of the token '<<'. I believe this makes more > sense than the original behaviour. Agreed. However, I suspect some will disagree and it may cause havoc in automated code that parses error messages. Presumably there's a way to get the old behavior, even if you're tracking all three locations? > - The macro expansion stack following the error message unwinds from > the macro which expansion most directly yielded token "<<". Each > element of the stack mentions the argument replacement point and the > expansion point locations that were exposed earlier. I like it. Though you might want a parameter which defines how many levels in the stack you want to display. I'm not sure on this one. > > * Limits > > I guess a pure marketing dude would elide this part :-) > > The most annoying limit is obviously memory consumption. Tracking the > location of every token across every macro expansion does consume > memory. I tried compiling some a translation here that heavily uses > the C++ standard library and I could see some 13% increase of memory > consumption over the entire compilation; note that the compilation was > consuming around 250MB without the feature. This is why the feature is > triggered by the -ftrack-macro-expansion flag. Without that flag, the > memory consumption stays roughly flat. The noticeable downside of that > flag is that it makes the code more complex. I think there possibly is > room to decrease this, but fundamentaly the consumption is going to > increase with the number of macro expanded multiplied by the number of > tokens per expansion. I'm surprised at the increase, not that it exists, but the magnitude. But if that's the cost, then we'll learn to deal with it. Having the flag definitely helps -- though I can see a point in the future where if this stuff works really well, we'll just turn it on by default and be done with it. Jeff