Bug 113987 - [12/13 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized
Summary: [12/13 Regression] Binding a reference to an uninitialized data member should...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 13.2.1
: P2 normal
Target Milestone: 12.5
Assignee: Marek Polacek
URL:
Keywords: diagnostic, patch
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
 
Reported: 2024-02-19 05:17 UTC by Fangrui Song
Modified: 2025-01-10 16:41 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work: 11.1.0
Known to fail: 12.1.0
Last reconfirmed: 2024-02-19 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fangrui Song 2024-02-19 05:17:49 UTC
https://godbolt.org/z/G7ndsTv5c (from https://github.com/llvm/llvm-project/pull/81179#issuecomment-1937082113)

struct t1 {
    t1(int);
};
struct t2 {
    t2(int&, int = 0);
};
struct t3 {
    t3(int&);
};
struct t4 {};
void f1(int&);
struct t {
    t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
    t1 v1;
    t2 v2;
    t3 v3;
    t4 v4;
    t1 v5;
    int i;
    int j;
};
int main() { t v1; }

GCC output
```
<source>: In constructor 't::t()':
<source>:13:14: warning: member 't::i' is used uninitialized [-Wuninitialized]
   13 |     t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
      |              ^
<source>:13:21: warning: member 't::i' is used uninitialized [-Wuninitialized]
   13 |     t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
      |                     ^
<source>:13:28: warning: member 't::i' is used uninitialized [-Wuninitialized]
   13 |     t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
      |                            ^
<source>: In constructor 't::t()':
<source>:13:11: warning: '*this.t::i' is used uninitialized [-Wuninitialized]
   13 |     t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
      |           ^~~~~
```

Clang output
```
<source>:13:14: warning: field 'i' is uninitialized when used here [-Wuninitialized]
   13 |     t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
      |              ^
<source>:13:54: warning: field 'i' is uninitialized when used here [-Wuninitialized]
   13 |     t() : v1(i), v2(i), v3(i), v4((f1(i), t4())), v5(i) {}
      |                                                      ^
2 warnings generated.
```

Clang suppresses diagnostics when binding a reference (t2, t3) to an uninitialized data member.


Smaller example:

  struct D {
    int a;
    int &b;
    int &c = a;
    D() : b(a) {}             // no warning ?!
    D(int x) : b(a), a(x) {}  // warning
  };
Comment 1 Fangrui Song 2024-02-19 05:18:48 UTC
BTW,
https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCXX/uninitialized.cpp has many member initializer list examples
Comment 2 Andrew Pinski 2024-02-19 05:26:02 UTC
This warning is from the front-end:
      else if (cp_tree_equal (TREE_OPERAND (init, 0), current_class_ref)
               && uninitialized->contains (field))
        {
          if (TYPE_REF_P (TREE_TYPE (field)))
            warning_at (EXPR_LOCATION (init), OPT_Wuninitialized,
                        "reference %qD is not yet bound to a value when used "
                        "here", field);
          else if (!INDIRECT_TYPE_P (type) || is_this_parameter (d->member))
            warning_at (EXPR_LOCATION (init), OPT_Wuninitialized,
                        "member %qD is used uninitialized", field);
          *walk_subtrees = false;
        }
Comment 3 Andrew Pinski 2024-02-19 05:26:44 UTC
Most likely started with r12-5391-g0790c8aacdfb4f .
Comment 4 Andrew Pinski 2024-02-19 05:32:01 UTC
(In reply to Fangrui Song from comment #1)
> BTW,
> https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCXX/
> uninitialized.cpp has many member initializer list examples

And r12-5391-g0790c8aacdfb4f added one testcase where clang produces a bogus warning too so it goes both ways really :).
Comment 5 Marek Polacek 2024-02-20 15:41:07 UTC
We already check !INDIRECT_TYPE_P, but here we're invoking a constructor, and we don't check that its parameters are !INDIRECT_TYPE_P.
Comment 7 GCC Commits 2024-02-29 17:41:49 UTC
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:b83f3cd3ff765fb82344b848b8a128763b7a4233

commit r14-9240-gb83f3cd3ff765fb82344b848b8a128763b7a4233
Author: Marek Polacek <polacek@redhat.com>
Date:   Tue Feb 20 15:55:55 2024 -0500

    c++: -Wuninitialized when binding a ref to uninit DM [PR113987]
    
    This PR asks that our -Wuninitialized for mem-initializers does
    not warn when binding a reference to an uninitialized data member.
    We already check !INDIRECT_TYPE_P in find_uninit_fields_r, but
    that won't catch binding a parameter of a reference type to an
    uninitialized field, as in:
    
      struct S { S (int&); };
      struct T {
          T() : s(i) {}
          S s;
          int i;
      };
    
    This patch adds a new function to handle this case.
    
            PR c++/113987
    
    gcc/cp/ChangeLog:
    
            * call.cc (conv_binds_to_reference_parm_p): New.
            * cp-tree.h (conv_binds_to_reference_parm_p): Declare.
            * init.cc (find_uninit_fields_r): Call it.
    
    gcc/testsuite/ChangeLog:
    
            * g++.dg/warn/Wuninitialized-15.C: Turn dg-warning into dg-bogus.
            * g++.dg/warn/Wuninitialized-34.C: New test.
Comment 8 Marek Polacek 2024-02-29 18:05:21 UTC
Fixed on trunk so far.  I suppose it should be safe enough to backport to 13, but I'm undecided if I want to do that.
Comment 9 Richard Biener 2024-06-20 09:15:00 UTC
GCC 12.4 is being released, retargeting bugs to GCC 12.5.
Comment 10 Marek Polacek 2025-01-10 16:41:49 UTC
Not backporting to 13.