On Nov 8, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
