This is the mail archive of the
mailing list for the GCC project.
Re: Designs for better debug info in GCC
Alexandre Oliva <firstname.lastname@example.org> writes:
> On Nov 7, 2007, Ian Lance Taylor <email@example.com> 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