1

I have a cmake/gcc project in which I have enabled several warnings and the flag -Werror.

I have noticed that some warnings are detected when I use the cmake flag -DCMAKE_BUILD_TYPE=Release, but they are not when I don't apply the above cmake flag. For example, one of these warnings is:

error: ‘var_name’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

I have read here: Set CFLAGS and CXXFLAGS options using CMake that there are several CMAKE_C_FLAGS variables for different build types, for instance, CMAKE_C_FLAGS_RELEASE.

I have tried to apply those variables for release and debug builds, but this time none of the above detect the warnings I'm expecting.

What I'm missing?

Dan
  • 2,452
  • 20
  • 45
  • **Absence** of `CMAKE_BUILD_TYPE` variable setting doesn't imply `Debug` build. The project may program setting build type by default, but if it does not do that, then the build type is "none", and **no specific flags** are applied. – Tsyvarev Jul 17 '19 at 21:43

1 Answers1

2

CMake's default/"debug" build profile entirely disables optimization, which prevents the compiler passes that perform transformations and static analysis needed to determine that a variable is used uninitialized from ever happening. While to some extent this improves debugging experience with single-step of source lines, as you've found it hides warnings and also tends to hide consequences of undefined behavior in your code.

Traditionally "disable optimizations entirely for non-release builds" has not been a thing among unix-oriented developers. It's a carry-over from common practice in the MSVC world that's reflective of CMake's origins and user base.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • How can tell gcc to never auto-initialize variables? – Dan Jul 17 '19 at 19:08
  • @Dan: It's not auto-initializing variables. What makes you think it is? The problem is that the compiler passes needed for analysis of program flow, to determine if the variable is uninitialized at the time of access, only happen as part of optimization. "Non-optimizing mode" is a very *unnatural* thing for a modern compiler, and lacks the capability to do any useful analysis. – R.. GitHub STOP HELPING ICE Jul 17 '19 at 19:11
  • I'm using std c99, as far as I understand, when using this standard, it initializes local variables to 0 (except in release mode it seems) – Dan Jul 17 '19 at 19:14
  • 1
    @Dan: No. That's just what happens to be present in the memory that they occupy. They are not initialized. – R.. GitHub STOP HELPING ICE Jul 17 '19 at 19:37
  • "... disables optimization, which prevents the compiler passes that perform transformations and static analysis needed to determine that a variable is used uninitialized from ever happening." - Are you sure about that? As far as I know, optimization (`-O`) and warnings options (`-W`) are completely **independent**. – Tsyvarev Jul 17 '19 at 21:45
  • @Tsyvarev: Yes. They're not completely independent. Some of them, especially this one which is heuristic and not precise, are only triggered during analysis that's performed for optimization purposes. In principle you could do the same analysis then throw it away in non-optimizing configuration, but GCC's architecture is not really designed to do that. – R.. GitHub STOP HELPING ICE Jul 17 '19 at 21:47
  • Hm, when I enable, say `-Werror=maybe-uninitialized` option, I expect the errors found to be the **same** whenever it is optimized or non-optimized build. From my opinion it is `gcc` who should enable needed analysis when it sees that option. – Tsyvarev Jul 17 '19 at 22:42
  • @Tsyvarev: Well it doesn't, and this is documented somewhere. `-O0` really just **should not be used**. Until CMake made it a thing again, almost nobody was using it. – R.. GitHub STOP HELPING ICE Jul 17 '19 at 23:25
  • OK, I have found some other questions about `-Werror=maybe-uninitialized` and optimization switches, like this one: https://stackoverflow.com/questions/47307538/why-gcc-does-not-report-uninitialized-variable. – Tsyvarev Jul 17 '19 at 23:59