# Steps to reproduce (in terms of terminal commands): $ cat test.cpp #include <vector> struct MyStruct { std::vector<char> vec; unsigned b; MyStruct(unsigned arg1): vec(b), b(arg1){} }; int main() { MyStruct m{1}; } $ g++ test.cpp -Wuninitialized -Wmaybe-uninitialized # Expected: A warning about `vec` being initialized in constructor with `b` field that is not yet initialized. # Actual The code silently compiles # Additional information The bug is specific to non-trivial types. E.g. if you replace `vector` with `unsigned`, the warning will work. However it doesn't for std∷vector or std∷list. It came up in a real project, where reorder of fields resulted in a bug that GCC doesn't warn about.
It works with optimization: > g++-8 t.C -Wuninitialized -Wmaybe-uninitialized -O t.C: In function ‘int main()’: t.C:7:34: warning: ‘m.MyStruct::b’ is used uninitialized in this function [-Wuninitialized] MyStruct(unsigned arg1): vec(b), b(arg1){} ^ the reason is that at -O0 all calls such as the constructor are left in place and thus the uninitialized use is not exposed to function-local analysis.
Or rather it is not the destructor call but the load of 'b' from *this that is not "optimized".
On the other hand, it looks like an "easy" case where the front-end could notice that we are using b as an rvalue before it is initialized and warn about it without relying on the middle-end. It could fall under order-of-initialization instead of uninitialized.
Duplicated *** This bug has been marked as a duplicate of bug 19808 ***