[Bug tree-optimization/97108] [9/10/11/12 Regression] -Wmaybe-uninitialized false positive

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |101912
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com,
                   |                            |rguenth at gcc dot gnu.org

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

> The backwards threader probably could be made to detect this case though. 
> I'm pretty sure we're not raising queries for COND_EXPRs  on the RHS of a
> statement, just for GIMPLE_COND statements.  So this block:
> 
> ;;   basic block 9, loop depth 0, count 708669601 (estimated locally), maybe
> hot
> ;;    prev block 8, next block 10, flags: (NEW, VISITED)
> ;;    pred:       8 [always]  count:346397698 (estimated locally)
> (FALLTHRU,EXECUTABLE)
> ;;                7 [51.1% (guessed)]  count:362271902 (estimated locally)
> (FALSE_VALUE,EXECUTABLE)
>   _2 = orig_err_26 != 2;
>   _1 = flags_8(D) == 0;
>   _3 = _2 & _1;
>   if (_3 != 0)
>     goto <bb 10>; [33.00%]
>   else
>     goto <bb 4>; [67.00%]

The original code gates the read from orig_err with !separate_stderr:

      if (separate_stderr
          && orig_err != STDERR_FILENO)
        _close (orig_err);

which is somehow lost in BB9 above, since the reads from both orig_err_26 and
separate_stderr (!flags) are occuring in the same block.

I've made a similar observation in PR101912.  I assume this eliding of the gate
is allowable per language rules?

However, even if the gate were there, I think we'd start to run into path
length issues.  For example, I see some of the paths starting at the 3->5 edge
(which contains the undefined read):

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

So I'm not even sure we could depend on the threader catching this since it's
handcuffed from attempting such long paths.

Crazy idea, but I wonder if we could plug the path solver to the uninit code. 
For instance, if we're going to warn on a use of orig_err_26, first query all
the paths from DEF to USE and see if any are reachable.  This would be cheaper
than a full blown threader, since we've only be chasing paths for places we're
already going to warn on.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
[Bug 101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c