[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]

[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |10.2.0, 11.0, 7.3.0, 8.3.0,
                   |                            |9.2.0
   Last reconfirmed|2017-09-04 00:00:00         |2021-4-13
             Blocks|                            |24639
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
Reconfirmed with GCC 11.


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/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]

[aldyh at gcc dot gnu.org]

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

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

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

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> Jump threading probably gives up because of the asm ().

Actually the problem is the number of instructions in the asm.

The path starting at 3->4 would elide the undefined read but the asm has a ton
of statements and the threadfull* passes fail to even look at the path:

Checking profitability of path (backwards):  bb:4 (18 insns) bb:3
  Control statement insns: 2
  Overall: 16 insns
  FAIL: Did not thread around loop and would copy too many statements.

Assuming estimate_num_insns() is correct for the asm inline, we can't depend on
the threader.

Hmmm, I keep thinking we need a path solver/ranger aware uninit pass :).

[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 51913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51913&action=edit
proof of concept to reduce uninit warnings with the path solver

[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
[from the POC patch]

It seems that every missed thread (due to inability of the threader,
or due to cost restraints) is a potential false positive for the
uninit code.  Perhaps what we need is a way to identify threading
opportunities without doing the actual threading.  The attached is a
proof-of-concept that does just that.

Basically a lof of these PRs look like:

x_5 = PHI <UNDEF(10), x_8(20), x_10(30)>
...
...
if (cond_8)
  use(x_5);

This looks like a path from the definition of x_5 to the cond_8 check.
If the incoming path through BB10 can be determined to elide the use
of x_5, we could disregard this as a false positive.

This patch solves PR82090, but it would need to be properly
incorporated into the uninit pass.  For instance, I'm finding paths
from USE back to DEF, but the uninit pass is in a much better position
to tell us what the starting point of the path is.  It's likely to be
further up the chain through a maze of feeding PHIs.

This is just meant as a stop gap to help in reducing the false
positive rate, nothing fancy.  Maybe the work by Martin Liska and
Richi on loop unswitching would be a better solution.

Anywhoo... Maybe someone with knowledge of the uninit pass could
explore this.  Just a thought.

[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]

[law at gcc dot gnu.org]

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

--- Comment #6 from Jeffrey A. Law <law at gcc dot gnu.org> ---
I never explored the idea, but Bodik has a discussion of recording infeasible
paths in the CFG which would seem to address this issue.  He was using the
concept in the context of coverage analysis -- the idea being if you were
supposed to be providing 100% coverage, then you have to know if there are
paths that simply can't be executed at runtime that were left in the CFG. 
Anyway...

If we find a thread, but fail to optimize it because of the cost -- we record
data in the CFG on the path infeasibility.  The uninit pass (or any pass for
that matter) could then query that data and realize the path isn't feasible and
suppress the warning in that case.

My concern with Bodik's approach is the marking and keeping those markings
up-to-date through the pipeline.

So that's one approach.

The other is to introduce the solver into the predicate analysis pass which
starts to touch on other ideas I've had.  Namely that thread discovery and
predicate analysis are closely related.  ie, we could be using predicate
analysis to discover more threading opportunities and we could be using the
path solver to prune out infeasible paths for the uninit (and other) passes by
integrating path solving into predicate analysis.  What you've done is the
first step in this direction.

[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]

[aldyh at gcc dot gnu.org]

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

--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #6)

> The other is to introduce the solver into the predicate analysis pass which
> starts to touch on other ideas I've had.  Namely that thread discovery and
> predicate analysis are closely related.  ie, we could be using predicate
> analysis to discover more threading opportunities and we could be using the
> path solver to prune out infeasible paths for the uninit (and other) passes
> by integrating path solving into predicate analysis.  What you've done is
> the first step in this direction.

It looks like compute_control_dep_chain builds a vectors of edges indicating
paths from DEF to USE.  We may be able to feed a variant of this to the path
solver to determine if the path is reachable.  That is, without having to
search for the path :).

Hmm, there may be something here.