https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- The problem is that -Og aimed at solving two problems that are often in conflict with each other - improving the debugging experience _and_ runtime performance. For the second goal it started as -O1 and then removing optimizations that make the debugging experience bad which is transforms that re-order things because then the debugging gets jumpy. For the first goal we wanted to make -fvar-tracking usable (not enabled at -O0) without big hits on compile-time because that also allows the second goal as not all locals are materialized on the stack. So yes, we probably should tune down inlining for -Og, possibly also by simply disabling the size/time estimation logic. Inlining helps when you single-step assembler instructions (because you have less instructions to execute), it shouldn't make much difference when single-stepping statements since the debugger should enter inlined bodies the same as not inlined bodies?
