[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498

Kai Tietz <ktietz at gcc dot gnu.org> changed:

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

--- Comment #13 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-10-15 17:10:11 
UTC ---
This bug seems to be caused by vrp's jump-threading and branching into
different if-branch

For example this case gets expanded by vrp to:

int g;
void bar();
void blah(int);

int foo (int n, int l, int m, int r)
{
  int v;

  int v;

  if ((n != 0) & (l != 0))
    v = r;

  if (m) g++;
  else   bar();

  if ( n && l)
      blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */

  if (l ) if ( n)
      blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */

  return 0;
}

foo (int n, int l, int m, int r)
{
  int v;
  int g.3;
  int g.2;
  _Bool D.2766;
  _Bool D.2765;
  _Bool D.2764;

<bb 2>:
  D.2764_3 = n_2(D) != 0;
  D.2765_5 = l_4(D) != 0;
  D.2766_6 = D.2764_3 & D.2765_5;
  if (D.2766_6 != 0)
    goto <bb 4>;
  else
    goto <bb 3>;

<bb 3>:

<bb 4>:
  # v_1 = PHI <v_7(D)(3), r_8(D)(2)>
  if (m_10(D) != 0)
    goto <bb 5>;
  else
    goto <bb 6>;

<bb 5>:
  g.2_11 = g;
  g.3_12 = g.2_11 + 1;
  g = g.3_12;
  goto <bb 7>;

<bb 6>:
  bar ();

<bb 7>:
  if (D.2766_6 != 0)
    goto <bb 8>;
  else
    goto <bb 9>;

<bb 8>:
  blah (v_1);
  goto <bb 13>;
<bb 9>:
  if (l_4(D) != 0)
    goto <bb 10>;
  else
    goto <bb 12>;

<bb 10>:
  if (n_2(D) != 0)
    goto <bb 11>;
  else
    goto <bb 12>;

<bb 11>:
  blah (v_1);

<bb 12>:
  return 0;

<bb 13>:
  goto <bb 10>;

}

Of interest is the insert goto at <bb 8> to <bb 10> via <bb 13>.
<bb 10> itself is the inner branch of the 'if (l ) if ( n)'.  So 'if ( n)' has
two users, and so it gets warned, as it isn't clear to later check, that <bb
10>'s condition is for <bb 13> also true. IMHO vrp needs to learn that <bb 11>
should be the target of <bb 13> instead.

That -mbranch-costs shows for such cases some effect, is caused by
combining/not-combining if-conditions.

To solve this, we shouldn't make differences in AST about branching-costs high
or low.  The tree-ssa-ifcombine pass should run before (and maybe after as now)
first vrp pass, and should try to merge if-s together as well.  In one of the
last gimple-passes then we should actually apply to conditions the branching
rule and break-up conditions to their if-chains.