On Dec 17, 2007, Joe Buck <[EMAIL PROTECTED]> wrote: > On Mon, Dec 17, 2007 at 11:11:46PM -0200, Alexandre Oliva wrote: >> Line number information has a well-defined meaning: it ought to >> represent the source code line that best represents the source-code >> construct that ended up implemented using that instruction.
> You implicitly assume that souch a source code line exists. Actually, no. I'm not sure where you got that impression, and how you came to the conclusion that I'd assign line numbers the way you have. To me, when you hoist something that is present in both blocks of a conditional, it probably makes more sense to give it the line number of the conditional, rather than that of either block. But I won't pretend to have thought very hard about this particular issue. For the time being, I'm focusing my efforts on local variable locations. Anyhow, very clearly you don't want to mark such hoisted-out computation as is_stmt. This should eliminate at least the solvable problem you're worried about. > out = a + b; > if (!cond) > out += c; > return out; > Furthermore, there isn't a place to put a breakpoint that will > trigger only for the case where cond is true, as you can on > unoptimized code. Yep. Sometimes code just is optimized away. Can't stop that without harming optimizations. If dwarf line number programs were smarter, we could perhaps encode multiple lines for the same instruction, along with conditions to tell when the instruction applies to such or such lines, and even more fancy stuff like that. But line number programs don't let us express this in Dwarf3. -- 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}
