[Bug middle-end/53922] New: VRP: semantic conflict between range_includes_zero_p and value_inside_range

["amker.cheng at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

             Bug #: 53922
           Summary: VRP: semantic conflict between range_includes_zero_p
                    and value_inside_range
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: amker.cheng@gmail.com


In tree-vrp.c
function value_inside_range returns:
          1 if VAL is inside value range VR (VR->MIN <= VAL <= VR->MAX),
          0 if VAL is not inside VR,
     -2 if we cannot tell either way.

While in function range_includes_zero_p, it:
         return (value_inside_range (zero, vr) == 1);
which is bogus.
Because when value_inside_range returns -2, there is the possibility that value
range includes zero.

For example:

int x(int a)
{
    return a;
}
int y(int a) __attribute__ ((weak));
int (*scan_func)(int);
extern int g;
int g = 0;
int main()
{
    if (g)
        scan_func = x;
    else
        scan_func = y;

    if (scan_func)
        g = scan_func(10);

    return 0;
}

compiled with command line:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -Os -S test.c -o test.S
-fdump-tree-all

The dump of vrp2 pass is:
main ()
{
  int (*<Tcc0>) (int) cstore.6;
  int g.2;
  int g.0;

<bb 2>:
  g.0_1 = g;
  if (g.0_1 != 0)
    goto <bb 3>;
  else
    goto <bb 4>;

<bb 3>:

<bb 4>:
  # cstore.6_9 = PHI <x(3), y(2)>
  scan_func = cstore.6_9;
  g.2_4 = cstore.6_9 (10);
  g = g.2_4;
  return 0;

}

Though the problem shows up with this case in gcc4.6 branch and -Os option on
arm, I think it exists in 4.7/4.8 too, just concealed by different gimple
statements.

I will work out a patch for this.