https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
--- Comment #41 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 11 Mar 2026, fredrik at dolda2000 dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 > > --- Comment #40 from Fredrik Tolf <fredrik at dolda2000 dot com> --- > >Assignments to local variables are a different topic, a bit less > >crucial for debugging. > > >such a resolution means that people will frequently end up using -O0 > >for debugging, and O0 is far more expensive than it needs to be for > >viable debugging. In particular -O0 is also lacking debug features, the most prominent being lack of -fvar-tracking support and thus missing debug info in the prologue/epilogue. > I would like to add here a question about what -Og is actually supposed to > mean. The manpage says -Og is to "Optimize debugging experience". My naive > interpretation of this sentence is that -Og is supposed to offer "the best" > debugging experience, better than any other option. Currently, that's very > obviously not true, -O0 giving an objectively better debugging experience. > > If -Og is supposed to be "the best balance" between performance and > debuggability, then that's fine, but then I think at least the documentation > should be updated to reflect this. The documentation does say @opindex Og @item -Og Optimize while keeping in mind debugging experience. @option{-Og} should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable blend of optimization, fast compilation and debugging experience especially for code with a high abstraction penalty. In contrast to @option{-O0}, this enables @option{-fvar-tracking-assignments} and @option{-fvar-tracking} which handle debug information in the prologue and epilogue of functions better than @option{-O0}. so it says "Optimize while keeping in mind debugging experiece.", it does not say "Optimize debugging experience". It's the go-do if -O0 compiled code is too slow to debug. It also get's you the features -O0 doesn't have. > The manpage also states that -Og offers optimization "while maintaining [...] > a good debugging experience". That too is a reasonable meaning of -Og, one > that > I think is useful and should be preserved if possible. Right now, I don't > personally find that -Og offers a particularly good debugging experience > (which > is why I always use -O0 instead), but I assume that's the core problem that > this bug is supposed to track, and which there is an intention to fix, one > that > I think would be a good thing. > > > TL;DR: There seems to be some confusion in what -Og really is supposed to > achieve. Indeed, that seems to be the case. IMO we should approach this from two sides - make -O0 debugging better and address some pain points of -Og. But making all variables live until end of scope defeats the goal of having optimized code. If we do that we should probably go back to assigning all user variables to stack slots to avoid excessive spilling when we do not perform upfront allocation of such vars. This will then defeat optimization which can, for example, be cruical if you have threads and recursion and run out of stack space.
