[Bug c++/108230] New: assert() spuriously activates maybe-initialized warning

[Bug c++/108230] New: assert() spuriously activates maybe-initialized warning

[shin.david at gmail dot com]

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

            Bug ID: 108230
           Summary: assert() spuriously activates maybe-initialized
                    warning
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shin.david at gmail dot com
  Target Milestone: ---

gcc-12.2 reports a maybe-uninitialized warning for the last line of the below
code if-and-only-if the macro ADD_ASSERT is defined:

#include <bitset>
#include <Eigen/Core>

using Array = Eigen::Array<float, -1, 1, 0, 3, 1>;

struct Tree {
  Array array;
  std::bitset<8> bitset;
};

auto func(Tree* tree) {
  int c = tree->array.rows();
  int d = tree->bitset.count();
#ifdef ADD_ASSERT
  assert(c==d);
#endif  // ADD_ASSERT
  Array e(c);
  for (int k = 0; k < d; ++k) e(k) = k;
  return e.sum() / (e + 1);
}

int main() {
  Tree tree;
  func(&tree);
}

This is a bug because adding this assert() should have no bearing on whether or
not the return statement might entail uninitialized memory usage.

gcc cmd1, generates warning: -Wmaybe-uninitialized -O3 -DADD_ASSERT
gcc cmd2, no warning:        -Wmaybe-uninitialized -O3

Godbolt link, which includes full gcc warning output:
https://godbolt.org/z/nv11aaKb6

This example, convoluted as it seems, appears to be a minimal reproducible
example. For example:

- Removing the for-loop makes the warning appear with both gcc cmds
- Replacing the return expression with something simpler like (e + 1) makes the
warning disappear with both gcc cmds
- Replacing std::bitset with something else also makes the warning disappear
with both gcc cmds

Eigen library version is 3.4.0.

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Can you attach the preprocessed source?

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

[shin.david at gmail dot com]

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

--- Comment #2 from David Shin <shin.david at gmail dot com> ---
The preprocessed source is 3.5M, which exceeds the file attachment size limit
of 1000K.

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to David Shin from comment #2)
> The preprocessed source is 3.5M, which exceeds the file attachment size
> limit of 1000K.

You can compress it since it is above the max attachment size limit.

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization,
                   |                            |needs-bisection,
                   |                            |needs-reduction
      Known to work|                            |13.0

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There is a missed jump threading before uninit1:

  if (_12 != 0)
    goto <bb 9>; [89.00%]
  else
    goto <bb 7>; [11.00%]

  <bb 7> [local count: 12992276]:
  D.172541 ={v} {CLOBBER(eol)};
  if (_12 == 0)
    goto <bb 20>; [51.12%]
  else
    goto <bb 8>; [48.88%]

  <bb 8> [local count: 6802844]:
  _130 = MEM[(const float &)&e];


The jump threading is fully fixed on the trunk for GCC 13.

For GCC 11, the jump threading is also missed but missed for a different
reason:
  _20 = __builtin_popcountl (_12);
...
  _24 = (long int) _20;
...
  if (_12 != 0)
    goto <bb 7>; [89.00%]
  else
    goto <bb 12>; [11.00%]

  <bb 7> [local count: 105119324]:
  if (_24 != 0)
    goto <bb 11>; [99.96%]
  else
    goto <bb 10>; [0.04%]

So there is no optimization of ((long)popcount(_12))!=0 into _12 != 0 in GCC 11
but that happens in GCC 12 and the jump threading is then missed but was fixed
in GCC 13.

The assert there causes the usage of _20 (d) in place of c in some cases which
causes some IR differences which influences the warning ...

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

[shin.david at gmail dot com]

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

--- Comment #5 from David Shin <shin.david at gmail dot com> ---
Indeed, no warning on trunk! Sorry, should have checked trunk version before
reporting this.

[Bug tree-optimization/108230] assert() spuriously activates maybe-initialized warning

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to David Shin from comment #5)
> Indeed, no warning on trunk! Sorry, should have checked trunk version before
> reporting this.

No it is a good thing to report as we might want to get it fixed for gcc 12.

[Bug tree-optimization/108230] [12 regression] assert() spuriously activates maybe-uninitialized warning

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|assert() spuriously         |[12 regression] assert()
                   |activates                   |spuriously activates
                   |maybe-uninitialized warning |maybe-uninitialized warning

--- Comment #7 from Sam James <sjames at gcc dot gnu.org> ---
10/11 are fine too, as is 13+