From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26374 invoked by alias); 8 Nov 2007 18:18:37 -0000 Received: (qmail 26352 invoked by uid 22791); 8 Nov 2007 18:18:35 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 Nov 2007 18:18:33 +0000 Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id lA8IITlO021757; Thu, 8 Nov 2007 18:18:29 GMT Received: from smtp.corp.google.com (spacemonkey1.corp.google.com [192.168.120.115]) by zps38.corp.google.com with ESMTP id lA8IISuY008576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Nov 2007 10:18:28 -0800 Received: from localhost.localdomain.google.com (adsl-76-249-168-94.dsl.pltn13.sbcglobal.net [76.249.168.94]) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id lA8IIOP9010989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Nov 2007 10:18:26 -0800 To: Alexandre Oliva Cc: "Richard Guenther" , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Designs for better debug info in GCC References: <84fc9c000711050327x74845c78ya18a3329fcf9e4d2@mail.gmail.com> From: Ian Lance Taylor Date: Thu, 08 Nov 2007 19:23:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2007-11/txt/msg00253.txt.bz2 Alexandre Oliva writes: > On Nov 7, 2007, Ian Lance Taylor wrote: > > >> Does it really matter? Do we compromise standards compliance (and so > >> violently, while at that) in any aspect of the compiler? > > > What standards are you talking about? > > Debug information standards such as DWARF-3. ... > Incorrectness in the compiler output is always a bug. No matter how > hard it is to implement, or how resource-intensive the solution is, > arguing that we've made a trade-off and decided to generate wrong > output for this case is a clever decision. I'm sorry, I've thought about it, but I don't buy this argument. I'm certainly willing to talk about improving debug information for optimized code, and clearly it is more important to more people than I initially thought. However, I don't think your arguments that this is an issue comparable to code correctness are valid. Incorrect generated code is a fatal problem in a compiler. Incorrect debugging information is a quality of implementation issue. > >> > We've fixed many many bugs and misoptimizations over the years due to > >> > NOTEs. I'm concerned that adding DEBUG_INSN in RTL repeats a mistake > >> > we've made in the past. > >> > >> That's a valid concern. However, per this reasoning, we might as well > >> push every operand in our IL to separate representations, because > >> there have been so many bugs and misoptimizations over the years, > >> especially when the representation didn't make transformations > >> trivially correct. > > > Please don't use strawman arguments. > > It's not, really. A reference to an object within a debug stmt or > insn is very much like any other operand, in that most optimizer > passes must keep them up to date. If you argue for pushing them > outside the IL, why would any other operands be different? I think you misread me. I didn't argue for pushing debugging information outside the IL. I argued against a specific implementation--DEBUG_INSN--based on our experience with similar implementations. Ian