This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Designs for better debug info in GCC


Alexandre Oliva <aoliva@redhat.com> writes:

> On Nov  7, 2007, Ian Lance Taylor <iant@google.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
implementations.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]