[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #15 from Alex Mohr  ---
Thank you Richard B, Richard G, Xi, Jonathan, Jakub, and Eric for all the great
info.  Much appreciated.

With more experience using '-Og -fno-inline' I've found that sometimes
inspecting local variables doesn't work -- "".  So I'll continue
using -O0 for now.

To offer my perspective as a user, I think the manual should step back a bit
from recommending -Og as the default opt level for the edit/debug cycle, at
least in its current state.  Or at the very least, some mention of caveats
would be valuable.

That said I love that you're pursuing this direction and I'm eager to see how
this develops going forward.  Cheers!

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #10 from Alex Mohr  ---
(In reply to Xi Ruoyao from comment #9)
> I believe the only real issue is imprecise documentation: "It is a better
> choice than -O0" has some caveats and it's not always true.

Is there a way to explicitly enable the compiler passes that collect debug info
that are disabled at -O0?

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #8 from Alex Mohr  ---
(In reply to Jonathan Wakely from comment #5)
> A 4x slowdown isn't really acceptable IMHO. At that point, why not just use
> -O0 instead?

I've been using -O0 for years.  I was trying to move to -Og because of this
from the manual; particularly the second sentence:

"-Og should be the optimization level of choice for the standard
edit-compile-debug cycle, offering a reasonable level of optimization while
maintaining fast compilation and a good debugging experience. It is a better
choice than -O0 for producing debuggable code because some compiler passes that
collect debug information are disabled at -O0."

I definitely do not want to lose debug info.  The speed improvement is a nice
bonus, but top-notch debugging is my main goal for my debug builds.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #2 from Alex Mohr  ---
Thanks much for looking at this, Richard.

I definitely understand what you're driving at with regard to stepping into
lots of C++ abstraction stuff.  But I think it gets blurry trying to
distinguish what's interesting to a human or not based on code size.

I think I could probably be convinced about inlining trivial getters, setters,
and forwarders like in your struct X. But I think code size doesn't work as the
deciding factor here. Just to illustrate, here's a modified example with '-Og
--param early-inlining-insns=0'.  The entire thing gets inlined, even though
every small function contains a conditional, and one even calls another:

struct Foo {
explicit Foo(int in) { m = in > 0 ? in : 0; }
int CalcFoo() const { int r = CalcBar(); return r < 0 ? -r : r; }
int CalcBar() const { return m > 20 ? 20 : m; }
int m;
};

int Test(int in) {
Foo f(in);
return f.CalcFoo() + f.CalcBar();
}

--

Test(int):
testedi, edi
mov eax, 0
cmovs   edi, eax
mov eax, 20
cmp edi, eax
cmovg   edi, eax
lea eax, [rdi+rdi]
ret

https://godbolt.org/z/hcsnzMrP9

On one hand it's awesome that the optimizer is so good... but this could be
pretty frustrating to debug.

Just FWIW when I compile with '-O0', I see a ~5x slowdown vs '-O2', but with
'-Og -fno-inline', I see just ~4x, so it's still a nice win over '-O0'.

[Bug c++/111243] New: The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

Bug ID: 111243
   Summary: The -Og option inlines functions, making for a poor
debugging experience.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amohr at amohr dot org
  Target Milestone: ---

The docs recommend using -Og for debug builds, but that option inlines
functions which makes single-stepping in debuggers difficult/impossible. 
Adding -fno-inline fixes it.

The docs for -Og say that it disables -finline-functions-called-once. Should
-Og also do -fno-inline?

Here's a small example showing the difference between plain '-Og' and '-Og
-fno-inline':

https://godbolt.org/z/evs73cPT1