[Bug tree-optimization/106511] New: [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[Bug tree-optimization/106511] New: [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[marxin at gcc dot gnu.org]

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

            Bug ID: 106511
           Summary: [13 Regression] New -Werror=maybe-uninitialized since
                    r13-1268-g8c99e307b20c502e
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: aldyh at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53404&action=edit
test-case

Knowing the warning has a significant false-positive rate, but still, it may be
an interesting test-case. It's reduced from xen package:

$ gcc bunzip.i -Werror=maybe-uninitialized -O1
bunzip2.c: In function ‘get_next_block’:
bunzip2.c:261:27: error: ‘length’ may be used uninitialized
[-Werror=maybe-uninitialized]
bunzip2.c:224:17: note: ‘length’ declared here
cc1: some warnings being treated as errors

[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-08-03
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |24639
   Target Milestone|---                         |13.0
           Keywords|                            |diagnostic


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/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |85316

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
There was a recent other PR with the very same issue.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |12.2.0

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Earlier GCC were confused enough to not diagnose this, they have the same
missed-optimization.

[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |law at gcc dot gnu.org

[Bug tree-optimization/106511] [13/14 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug tree-optimization/106511] [13/14 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.

[Bug tree-optimization/106511] [13/14 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[amacleod at redhat dot com]

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

--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #2)
> VRP could use max_stmt_executions here (note it doesn't properly handle loop
> nests so the name is somewhat misleading)

Given some arbitrary statement S, how do I find the relevant loop pointer to
pass to max_stmt_executions?    I don't suppose there is a generic version
which will take care of that lookup?

This seems like something the phi analyzer could easily use to calculate the
number of times the modifier statement triggers when we have loop PHIs and some
other PHI in parallel.. if I can easily ask how many times stmt S is
executed...

[Bug tree-optimization/106511] [13/14 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[amacleod at redhat dot com]

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

--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #2)
> VRP could use max_stmt_executions here (note it doesn't properly handle loop
> nests so the name is somewhat misleading)

Do you have to ask for max_stmt_executions on each loop nest for the stmt to
get the real total?  and multiple them all together?  or can you only count on
loop_outer()?

[Bug tree-optimization/106511] [13/14 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #8)
> (In reply to Richard Biener from comment #2)
> > VRP could use max_stmt_executions here (note it doesn't properly handle loop
> > nests so the name is somewhat misleading)
> 
> Do you have to ask for max_stmt_executions on each loop nest for the stmt to
> get the real total?  and multiple them all together?  or can you only count
> on loop_outer()?

max_stmt_executions is for the loop you pass, not including outer loop
(or containing irreducible region) iterations.

The loop you usually pass is gimple_bb (stmt)->loop_father which is the
immediately containing loop.  This will be useful only when the PHI
we want to analyze is in the very same loop, if it is in an outer loop
then things become more complicated (you then could multiply by
max_loop_iterations of the containing loop maybe - but start simple ;))