[Bug c++/100115] New: Bogus -Wmaybe-uninitialized warning with -O3

[Bug c++/100115] New: Bogus -Wmaybe-uninitialized warning with -O3

[boris at kolpackov dot net]

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

            Bug ID: 100115
           Summary: Bogus -Wmaybe-uninitialized warning with -O3
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: boris at kolpackov dot net
  Target Milestone: ---

Created attachment 50615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50615&action=edit
Reproducer

The attached translation unit produces a bogus "may be used uninitialized"
warning:

$ g++-10 -Wmaybe-uninitialized -O3 -std=c++2a -fdirectives-only -c driver.ii
In file included from
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.mxx:550,
                 from driver.cxx:32:
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.ixx:
In function ‘int main(int, const char**)’:
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.ixx:345:17:
warning: ‘ate’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
  345 |     thread_env_ = v;
      |     ~~~~~~~~~~~~^~~
driver.cxx:392:19: note: ‘ate’ was declared here
  392 |   auto_thread_env ate (tevars);
      |                   ^~~

The same with GCC 11:

$ g++-11 -Wmaybe-uninitialized -O3 -std=c++2a -fdirectives-only -c driver.ii
In file included from
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.mxx:550,
                 from driver.cxx:32:
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.ixx:
In function ‘int main(int, const char**)’:
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.ixx:345:17:
warning: ‘*(const char* const**)((char*)&ate + offsetof(butl::auto_thread_env,
butl::auto_thread_env::prev_env.std::optional<const char*
const*>::<unnamed>.std::_Optional_base<const char* const*, true,
true>::<unnamed>))’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
  345 |     thread_env_ = v;
      |     ~~~~~~~~~~~~^~~
driver.cxx:392:19: note: ‘*(const char* const**)((char*)&ate +
offsetof(butl::auto_thread_env,
butl::auto_thread_env::prev_env.std::optional<const char*
const*>::<unnamed>.std::_Optional_base<const char* const*, true,
true>::<unnamed>))’ was declared here
  392 |   auto_thread_env ate (tevars);
      |                   ^~~

In fact, I get a variant of this warning going all the way to GCC 4.9. The
driver.ii file was prepared on Linux (with -fdirectives-only).

[Bug tree-optimization/100115] Bogus -Wmaybe-uninitialized warning with -O3

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |tree-optimization
                 CC|                            |msebor at gcc dot gnu.org
           Keywords|                            |diagnostic
             Blocks|                            |24639

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
I can confirm the warning but the test case is far too big for me to say
whether or not it's valid.  As it turns out, the test case is also too big for
GCC as it exceeds at least one internal limit named MAX_CHAIN_LEN.  The limit
is hardcoded to an exceedingly low value of 5 but with the test case reaches
77.  Exceeding this limit can lead to either false positives or negatives.  But
bumping it way up doesn't avoid the warning so something else is going on.

I'm trying to reduce the test case to something manageable but that can take
many hours, even days.  It would be really helpful if you could trim it down a
bit, e.g., by removing the biggest non-essentials like <iostream>.

That being said, the context of the warning mentions std::optional which has
been known to be challenging for analysis and has led to false positives (see
pr80635 and related) as well as less than optimal code in the past, so I expect
this is going to caused by a similar limitation.


Referenced Bugs:

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

[Bug tree-optimization/100115] Bogus -Wmaybe-uninitialized warning with -O3

[boris at kolpackov dot net]

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

--- Comment #2 from Boris Kolpackov <boris at kolpackov dot net> ---
> I'm trying to reduce the test case to something manageable but that can take many hours, even days.

Right. On our side we have spent hours, even days trying to suppress this
warning (both by rearranging the code and with #pragma) but it keep popping up
in different places and on different targets (MinGW, Mac OS, etc). In fact,
we've wasted so much time on chasing this (and similar issues in the past),
that I am seriously considering just globally disabling this warning since it
seems more trouble than it's worth. Sorry, just venting a bit here...

> It would be really helpful if you could trim it down a bit, e.g., by removing the biggest non-essentials like <iostream>.

I will try. The thing is, such simplifications often make the warning
disappear. We have tens of similar code fragments in our codebase, but only
this one triggers a warning on x86_64-linux (other places trigger it on MinGW
and Mac OS).

> That being said, the context of the warning mentions std::optional which has been known to be challenging for analysis [...]

Yes, I can confirm that most of the issues with this warning we've encountered
in the past involved std::optional.

[Bug tree-optimization/100115] Bogus -Wmaybe-uninitialized warning with -O3

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
The reason why the warning tends to disappear in a simpler test case is because
of the limit (I just had it happen with my reduction).  Don't spend more time
on it than you already have, I'll work with the attached translation unit.  The
warning is exquisitely sensitive to optimizations so when GCC doesn't optimize
something in a way that lets it prove the uninitialized read is impossible, it
triggers.  I'm hoping to improve this for GCC 12.