[Bug c++/100047] New: False -Wmaybe-uninitialized on one var depending on type of other var

[Bug c++/100047] New: False -Wmaybe-uninitialized on one var depending on type of other var

[gccbugbjorn at fahller dot se]

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

            Bug ID: 100047
           Summary: False -Wmaybe-uninitialized on one var depending on
                    type of other var
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gccbugbjorn at fahller dot se
  Target Milestone: ---

With the following C++17 code, there's a warning that m_size can be used
uninitialized if m_ptr is a std::unique_ptr<>, but not if it is a raw pointer.
This only happens when some optimization is enabled. -Og is enough. The bug
also applies to gcc-10, gcc-9 and gcc-8 (have not checked older versions).

#include <cstdint>
#include <cstdlib>
#include <optional>
#include <memory>
#include <string>

#if EXPOSE_BUG
using buffer_ptr = std::unique_ptr<uint8_t>;
#else
using buffer_ptr = const uint8_t*;
#endif

const uint8_t* get(const std::unique_ptr<uint8_t>& ptr)
{
    return ptr.get();
}
const uint8_t* get(const uint8_t* ptr)
{
    return ptr;
}

class packet_buffer
{
public:
    using const_iterator = const uint8_t*;
    packet_buffer() : m_ptr(nullptr), m_size(0) {}
    packet_buffer(buffer_ptr ptr, uint16_t size)
        : m_ptr(std::move(ptr)), m_size(size)
    {
    }
    size_t size() const { return m_size; }           // <- here
    const uint8_t* data() const { return get(m_ptr); }
    const_iterator begin() const { return data(); }
    const_iterator end() const { return data() + size(); }
private:
    buffer_ptr m_ptr;
    uint16_t m_size = 0;
};


std::string func()
{
    auto f =
        [](std::optional<packet_buffer> result) {
          auto&& b = result.value();
          return std::string(b.begin(), b.end());
        };
    return f(std::nullopt);
}

Godbolt link:
https://godbolt.org/z/63z8qzcxv

[Bug c++/100047] False -Wmaybe-uninitialized on one var depending on type of other var

[gccbugbjorn at fahller dot se]

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

--- Comment #1 from Björn Fahller <gccbugbjorn at fahller dot se> ---
Created attachment 50570
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50570&action=edit
Test program exposing the bug

bf@pteranodon /tmp> g++-10 -c -std=c++17 -Wmaybe-uninitialized ./t.cpp -Og # no
warning

bf@pteranodon /tmp> g++-10 -c -std=c++17 -DEXPOSE_BUG -Wmaybe-uninitialized
./t.cpp -Og
./t.cpp: In function ‘std::string func()’:
./t.cpp:30:34: warning: ‘<anonymous>.packet_buffer::m_size’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
   30 |     size_t size() const { return m_size; }            // <- here
      |                                  ^~~~~~

[Bug tree-optimization/100047] False -Wmaybe-uninitialized on one var depending on type of other var

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |tree-optimization
                 CC|                            |msebor at gcc dot gnu.org
             Blocks|                            |78394, 82738
   Last reconfirmed|                            |2021-04-12
      Known to fail|                            |10.2.0, 11.0, 8.3.0, 9.3.0

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
Confirmed with GCC 11 and 10 and -Og only with the GCC 11 IL below.  The
warning depends on a number of optimizations only a few of which are enabled at
-Og so it has  a higher rate of false positives there.  For GCC 12 with -Og we
might consider removing -Wmaybe-uninitialized from -Wall.

  <bb 2> [local count: 1073741824]:
  # .MEM_10 = VDEF <.MEM_1(D)>
  D.56209 = D.55716;
  # .MEM_11 = VDEF <.MEM_10>
  D.51082 ={v} {CLOBBER};
  # .MEM_12 = VDEF <.MEM_11>
  MEM[(union _Storage *)&D.51082] ={v} {CLOBBER};
  # .MEM_13 = VDEF <.MEM_12>
  MEM[(struct _Optional_payload_base *)&D.51082]._M_engaged = 0;   <<< store
  # .MEM_14 = VDEF <.MEM_13>
  D.56209 ={v} {CLOBBER};
  # VUSE <.MEM_14>
  _34 = MEM[(const struct _Optional_base
*)&D.51082]._M_payload.D.50287.D.50137._M_engaged;   <<< read
  if (_34 != 0)                                                    <<< not
folded
    goto <bb 3>; [100.00%]
  else
    goto <bb 5>; [0.00%]

  <bb 3> [local count: 1073741824]:
  # VUSE <.MEM_14>
  _36 = get (&MEM[(const struct packet_buffer *)&D.51082].m_ptr);
  # VUSE <.MEM_14>
  _37 = MEM[(const struct packet_buffer *)&D.51082].m_size;        <<<
-Wmaybe-uninitialized


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
[Bug 78394] False positives of maybe-uninitialized with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738
[Bug 82738] [meta-bug] issues with the -Og optimization level

[Bug tree-optimization/100047] False -Wmaybe-uninitialized on one var depending on type of other var

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |law at gcc dot gnu.org

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #2)
> Confirmed with GCC 11 and 10 and -Og only with the GCC 11 IL below.  The
> warning depends on a number of optimizations only a few of which are enabled
> at -Og so it has  a higher rate of false positives there.  For GCC 12 with
> -Og we might consider removing -Wmaybe-uninitialized from -Wall.

The threaders reduce the false positive rate for -Wuninitialized and friends,
however hardly any of them run at -O1 and -Og:

$ ./cc1 a.c -fdump-tree-all-details -quiet -I/tmp -Og -Wall
$ ls a.c.*thread*
a.c.034t.ethread

I think the only semi-useful threader at -O1 is DOM which uses evrp under the
covers.

An uneducated suggestion would be to remove these warnings from Wall at < O2.

Though I think if we convert the threading done at DOM to use the backward
threader (when ranger can do floats), we should be able to get this at -O1,
assuming we agree on the time penalty.