On Feb 26, 2015, Richard Biener <richard.guent...@gmail.com> wrote: > and more concentrating on the effect of your patch as opposed to > debug stmt philosophy.
> (which looks reasonable minus code-motion issues). > (but we might still want to compute it during var-tracking > if at a later PC range the scope will be active again). By taking debug stmt philosophy out of your reasoning, you come to a conclusion that directly contradicts the very philosophy. I.e., you're not setting the philosophy aside, you're setting yourself up for failure within that philosophy. Your note on code-motion issues shows another weakness, not in the philosophy I endorse, but on rather on the one you do. If annotations don't move, and they carry all the information debuggers need to care about, there's no code-motion issue whatsoever, and moving executable instructions would not have any effects whatsoever. Sure, we're not there yet, but if we want to get there, taking steps in the opposite direction won't take us there any time soon. > Thus consider the suggestion to insert reset debug insns at the beginning > of var-tracking and at points where a scope becomes dead (thus after > points where in a backward CFG walk a scope becomes live). The point where the scope becomes dead under what philosophical line? I believe we've already established that trying to recover that information after throwing it away is cheaper but error prone. I believe we've already agreed that we don't want debug information to be incorrect. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer