[Bug middle-end/87489] [8/9/10 Regression] Spurious -Wnonnull warning

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.4                         |11.0

--- Comment #11 from Jeffrey A. Law <law at redhat dot com> ---
A few notes.

After FRE3 would be the first point where things are optimized enough to avoid
the warning.  Though in general pass order juggling is not the way to solve
these kinds of problems.

To fix this without pass juggling we'd have to improve something between
inlining and CCP2 inclusive.  Inlining is necessary to expose the constants.  I
don't any good pass between those points to optimize this mess:

;;   basic block 2, loop depth 0
;;    pred:       ENTRY
  xl_xinfo.xinfo = 0;
  _3 = xl_xinfo.xinfo;
  if (_3 != 0)
    goto <bb 3>; [33.00%]
  else
    goto <bb 4>; [67.00%]
;;    succ:       3
;;                4

;;   basic block 3, loop depth 0
;;    pred:       2
  XLogRegisterData (&xl_xinfo.xinfo, 4);
;;    succ:       4

;;   basic block 4, loop depth 0
;;    pred:       2
;;                3
  _4 = xl_xinfo.xinfo;
  _5 = _4 & 16;
  if (_5 != 0)
    goto <bb 5>; [33.00%]
  else
    goto <bb 6>; [67.00%]
;;    succ:       5
;;                6

;;   basic block 5, loop depth 0
;;    pred:       4
  _6 = strlen (0B);
  _7 = (unsigned int) _6;
  _8 = _7 + 1;
  _9 = (int) _8;
  XLogRegisterData (0B, _9);
;;    succ:       6


To optimize things enough to avoid the false positive we'd have to realize that
_3 is zero, which in turn would allow removal of the conditional at the end of
bb2 and all of bb3.  Then we'd have to discover that _4 is zero, which is only
possible *after* removing bb3.  Once we discover that _4 is zero, then we'd be
able to optimize away the conditional at the end of bb4 and avoid the false
positive.

Now the first step could be bolted onto CCP.  It's not terribly hard.  But the
secondary effects we need (specifically removing bb3 and discovery that _4 is
always zero) are quite difficult to capture at this point, particularly since
they occur as post-pass cleanups.

So I don't see improving CCP as a viable path to addressing this problem.  What
would probably work better would be a FRE pass between CCP and the IPA
warnings.  But that's pretty expensive.  SImilarly running DOM + threading
between CCP and the IPA warnings would be sufficient to find and eliminate the
dead code.

As noted we could move this warning late, but that brings its own set of
problems.

Realistically this is going to have to defer to gcc-11 and likely beyond.