https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Bruno Haible from comment #8) > (In reply to Richard Biener from comment #7) > > It's -fvar-tracking, not -fvar-tracking-assignments. At -O0 debug info > > during the prologue is unreliable without that. > > Then how about enabling -fvar-tracking automatically when "-g" or "-ggdb" is > requested and the debug format supports it? There are major problems with that. var-tracking is very compile time intensive, so it would significantly slow down -O0 compilation. And, most of the time at -O0 variables live in their memory slots, so that var-tracking time would be also wasted. The only things which need var-tracking at -O0 are: 1) register variables (or whatever else doesn't get an allocated stack slot) 2) variables at the start and end of their lifetime, where they are not yet in their stack slot or no longer in them (so, often function prologues and epilogues, or say for VLAs before everything is set up etc.) So, as written in other PRs, for -O0 we'd likely want to invent some cheaper var-tracking variant which would only track the above 2 and not waste time on the rest. > The documentation > https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Debugging-Options.html says: > "It is enabled by default when compiling with optimization (-Os, -O, -O2, > …), debugging information (-g) and the debug info format supports it." > > Why not also enable it when compiling _without_ optimization? > > I'm not using "-Og" because the documentation > https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Optimize-Options.html says > "-Og enables all -O1 optimization flags except for those that may interfere > with debugging", but what I want is optimal debugging and don't want to > spend CPU cycles on optimization. As for -Og, -Og doesn't perform too many optimizations and in function prologues code is usually better debuggable than with -O0. But there is one major obstackle also recorded in various PRs, we don't artificially make all vars used at the end of their scope, which means that if some var is unused after certain point in a function, it might no longer be available and e.g. DWARF5 DW_OP_entry_value used as the last resort; but that doesn't work always. For the -fsanitize=address case, the thing is that the marking of end of prologue is something we do during function prologue generation in pro_and_epilogue (or debugger does that from scanning the function IL). While the asan "prologue" is something emitted during RTL expansion and so for pro_and_epilogue seen as part of function body.
