Bug 89192 - -Wuninitialized doesn't warn about a vector initialization with uninitialized field
Summary: -Wuninitialized doesn't warn about a vector initialization with uninitialized...
Status: RESOLVED DUPLICATE of bug 19808
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 8.2.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
 
Reported: 2019-02-04 14:41 UTC by Konstantin Kharlamov
Modified: 2019-11-02 15:19 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Kharlamov 2019-02-04 14:41:54 UTC
# 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.
Comment 1 Richard Biener 2019-02-04 14:47:44 UTC
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.
Comment 2 Richard Biener 2019-02-04 14:49:22 UTC
Or rather it is not the destructor call but the load of 'b' from *this that is
not "optimized".
Comment 3 Marc Glisse 2019-02-04 15:05:42 UTC
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.
Comment 4 Manuel López-Ibáñez 2019-11-02 15:19:58 UTC
Duplicated

*** This bug has been marked as a duplicate of bug 19808 ***