31–40 of 111 posts
The std::move -> call issue has been fixed in clang-15.
> Clang 15.x, also motivated by my #53689 issue, also introduced a similar folding pass for the same functions chosen by GCC (plus std::move_if_noexcept, which I assume GCC maintainers forgot about). This one seems to be enabled by default – see a comparison between Clang 14.x and Clang 15.x on Compiler Explorer.
Have any multibillion dollar game (etc.) companies invested any resources into debug build modes in the open source compilers they develop with? Seems like it should be trivial to tie team productivity rates to quality of the debug experience.
For both productivity and practical reasons (the game still has to be somewhat playable), the use of pragmas to disable optimizations for the file/function of interest is generally recommended over a full debug build.
If relevant corps started adding the same hint flags in every toolchain, then conversations about the need for standard mechanisms might be interesting. But even if they don't get standardized, at least some common and portable fundamental libraries can support macros to smooth over the differences.
Earlier quoted context omitted.
Not exactly what you were asking, but RAD tried to build a debugger for Linux^1, but the project died. I’ve heard the people at RAD described as hard core old school programmers, so if they struggled with this it must just be a hard problem 1. http://www.radgametools.com/debug.htm
>> To put it bluntly, debugging on Linux is just really bad. We believe it is the biggest roadblock to great software for that platform. That article is ~10 years old, is that still true?
For me, gdb is a last resort tool, and none of its frontends satisfy me (Qt Creator is the least bad I tried). I generally prefer developing on Linux, but for me, the Visual Studio (not Code) debugger is the one thing that Windows does way better.
> Even if -Og was ubiquitous, it is still suboptimal to -O0: it can still inline code a bit too aggressively for an effective debugging session. IMO, the problem is not so much the inlining, but the sad state of the optimization passes losing track of many things and producing useless debug info.
It's not just inlining. With -Og (clang or gcc), the debugger frequently can't even tell me the value of function arguments because they've been "optimized out".
I wondered what code I had written that caused such a massive performance hit in debug mode. So I went to profile my code in a debug build to find out. Lo and behold, something like 90% of the CPU time was wasted doing lookups from std::unordered_map because of debug iterators. I tried everything I could to just turn debug iterators off, and eventually gave up and switched to robin_hood::unordered_map which runs great in debug and release. Now I have an unwarranted aversion to the std lib, even though it really is great so long as you're running it in release mode.
MSVC lacks -Og because it instead treats inlining, optimization, and inclusion of debug information as separate, orthogonal choices. These days I rarely build a whole MSVC project as "Debug" without optimization. Instead I enable both optimization and debug information, so I always get call stacks and line-by-line stepping ability. When I end up debugging some file where the optimizations inhibit debuggability, I'll…
It’s always nice to understand more about why game developers do the weird things they do. I always buried and run in “RelWithDebInfo”, then if I really need it, I’ll throw `#pragma clang optimize off` around the code that the debugger can’t see into.
Really nice tip to know! I've also struggled a lot with slow debug performance, so this will be very handy when I know there's a bug somewhere in a specific region but can't pinpoint exactly where.
I'm with Kernigham and Pike: the debugger is for getting a stack trace out of core dumps. Printf is for debugging.
I ran into these problems with std::unordered_map. While developing my game, I would always run it in debug mode because I need to debug it. Loading a game world was taking around 12 seconds, and it was beginning to grate on me because of the increased iteration times. So I decided to profile it and see what was taking so long. I compiled in release mode to begin debugging, and it magically took the world load time d…
MSVC lacks -Og because it instead treats inlining, optimization, and inclusion of debug information as separate, orthogonal choices. These days I rarely build a whole MSVC project as "Debug" without optimization. Instead I enable both optimization and debug information, so I always get call stacks and line-by-line stepping ability. When I end up debugging some file where the optimizations inhibit debuggability, I'll…
I think you misunderstand what -Og is. All of the major compilers treat optimization and inclusion of debug information as separate choices, and generating debug symbols for optimized release builds is a very normal thing to do. GCC's -Og is just an attempt at selecting a set of optimizations which don't cause too many problems for debuggability.