Robert Dewar wrote:
> Ian Lance Taylor wrote:
>> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>>
>>> 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?
>>
>> I don't see any point to going around this point again, so I'll just
>> note that I disagree.
>
> Well I very much agree.
The trick is that we're being asked to give a binary answer ("is it a
correctness issue?") when it's not really a binary issue.
Clearly, for some users, incorrect debugging information on optimized
code is not a terribly big deal. It's certainly less important to many
users than that the program get the right answer. On the other hand,
there are no doubt users where, whether for debugging, certification, or
whatever, it's vitally important that the debugging information meet
some standard of accuracy.
Part of my concern with this whole discussion is that we seem to be
saying we want the debugging information to be better, but not saying
very clearly what the requirements on better are. Are we going to
consider it a bug if the value of a variable is unavailable, but the
debugging information says it is available? (Yes, this seems like a bug
to me.) What if an old value is available, but a simple-minded reading
of the program would have now assigned a new value? (No, I wouldn't
consider this a bug.) What if the value is available in two places, and
we only describe one of them? (No, I wouldn't consider this a bug.)
What if the value is available, but we say that it isn't because we lost
track of it at some point? (I would say "it depends".)
We could certainly track user variables through SSA and RTL, at least
insofar as knowing that some REGs refer to SSA names that refer to user
VAR_DECLs. We can use dataflow analysis to compute where those values
(might) die. Thus, we can probably do a reasonable job of guaranteeing
that when we say a variable is somewhere, it is in fact in that place.
I don't yet understand what else we're trying to do.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
