[Bug middle-end/113987] New: Binding a reference to an uninitialized data member should not cause -Wuninitialized

[Bug middle-end/113987] New: Binding a reference to an uninitialized data member should not cause -Wuninitialized

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

            Bug ID: 113987
           Summary: Binding a reference to an uninitialized data member
                    should not cause -Wuninitialized
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: i at maskray dot me
  Target Milestone: ---

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
  };

[Bug middle-end/113987] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

--- Comment #1 from Fangrui Song <i at maskray dot me> ---
BTW,
https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCXX/uninitialized.cpp
has many member initializer list examples

[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.4
      Known to fail|                            |12.1.0
             Blocks|24639                       |
      Known to work|                            |11.1.0
            Summary|Binding a reference to an   |[12/13/14 Regression]
                   |uninitialized data member   |Binding a reference to an
                   |should not cause            |uninitialized data member
                   |-Wuninitialized             |should not cause
                   |                            |-Wuninitialized

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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;
        }


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Most likely started with r12-5391-g0790c8aacdfb4f .

[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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 :).

[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |mpolacek at gcc dot gnu.org

[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
            Version|unknown                     |13.2.1
   Last reconfirmed|                            |2024-02-19

[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
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.

[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |mpolacek at gcc dot gnu.org

[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646105.html

[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
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.

[Bug c++/113987] [12/13 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12/13/14 Regression]       |[12/13 Regression] Binding
                   |Binding a reference to an   |a reference to an
                   |uninitialized data member   |uninitialized data member
                   |should not cause            |should not cause
                   |-Wuninitialized             |-Wuninitialized

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
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.