From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18587 invoked by alias); 8 Nov 2007 20:07:34 -0000 Received: (qmail 18480 invoked by uid 22791); 8 Nov 2007 20:07:33 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 Nov 2007 20:07:30 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lA8K7PQ4018998; Thu, 8 Nov 2007 15:07:25 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lA8K7P9f018820; Thu, 8 Nov 2007 15:07:25 -0500 Received: from free.oliva.athome.lsd.ic.unicamp.br (vpn-15-91.rdu.redhat.com [10.11.15.91]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lA8K7Nts018679; Thu, 8 Nov 2007 15:07:24 -0500 Received: from free.oliva.athome.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.oliva.athome.lsd.ic.unicamp.br (8.14.1/8.14.1) with ESMTP id lA8K7MDU014588; Thu, 8 Nov 2007 18:07:22 -0200 Received: (from aoliva@localhost) by free.oliva.athome.lsd.ic.unicamp.br (8.14.1/8.14.1/Submit) id lA8K7LUn014586; Thu, 8 Nov 2007 18:07:21 -0200 To: Ian Lance Taylor 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: Alexandre Oliva Errors-To: aoliva@oliva.athome.lsd.ic.unicamp.br Date: Fri, 09 Nov 2007 00:08:00 -0000 In-Reply-To: (Ian Lance Taylor's message of "08 Nov 2007 10\:17\:52 -0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00259.txt.bz2 On Nov 8, 2007, Ian Lance Taylor wrote: > However, I don't think your arguments that this is > an issue comparable to code correctness are valid. It *is* code correctness. Say, if the linker emitted incorrect addresses in an executable, but the kernel and dynamic loader didn't rely on those addresses, would it not still be a bug in the linker? And then, if those tools started relying on those addresses and exposed the problem, would it be right to tell them they must not rely on them because they were broken in the past and we don't feel like correcting the linker? So... The compiler is outputting code that tells other tools where to look for certain variables at run time, but it's putting incorrect information there. How can you possibly argue that this is not a code correctness issue? > Incorrect generated code is a fatal problem in a compiler. > Incorrect debugging information is a quality of implementation > issue. Incomplete debugging information is a quality of implementation, just like missed optimizations. Incorrect compiler output is a bug. Claiming it's not just because tools you happen to rely on don't care about that piece of information won't make it any less of a bug. It may make it a less important bug for some time, but it's still a bug. >> >> > 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. Do you remember any other notes that contained actual rtx expressions and expected optimization passes to keep them accurate? All notes (as in matching NOTE_P) I remember didn't really contain rtx expressions. The first exception I remember is VAR_LOCATION, and this one explicitly does *not* want to be updated, for it's generated so late in the process. Conversely, REG_NOTES do contain rtx, and they often have to be updated, so that's the right representation for them. Do you think we'd gain anything by moving them to a separate, out-of-line representation? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}