https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108230
Bug ID: 108230
Summary: assert() spuriously activates maybe-initialized
warning
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: shin.david at gmail dot com
Target Milestone: ---
gcc-12.2 reports a maybe-uninitialized warning for the last line of the below
code if-and-only-if the macro ADD_ASSERT is defined:
#include <bitset>
#include <Eigen/Core>
using Array = Eigen::Array<float, -1, 1, 0, 3, 1>;
struct Tree {
Array array;
std::bitset<8> bitset;
};
auto func(Tree* tree) {
int c = tree->array.rows();
int d = tree->bitset.count();
#ifdef ADD_ASSERT
assert(c==d);
#endif // ADD_ASSERT
Array e(c);
for (int k = 0; k < d; ++k) e(k) = k;
return e.sum() / (e + 1);
}
int main() {
Tree tree;
func(&tree);
}
This is a bug because adding this assert() should have no bearing on whether or
not the return statement might entail uninitialized memory usage.
gcc cmd1, generates warning: -Wmaybe-uninitialized -O3 -DADD_ASSERT
gcc cmd2, no warning: -Wmaybe-uninitialized -O3
Godbolt link, which includes full gcc warning output:
https://godbolt.org/z/nv11aaKb6
This example, convoluted as it seems, appears to be a minimal reproducible
example. For example:
- Removing the for-loop makes the warning appear with both gcc cmds
- Replacing the return expression with something simpler like (e + 1) makes the
warning disappear with both gcc cmds
- Replacing std::bitset with something else also makes the warning disappear
with both gcc cmds
Eigen library version is 3.4.0.
