[Bug middle-end/64006] __builtin_mul_overflow fails to signal overflow

[Bug middle-end/64006] __builtin_mul_overflow fails to signal overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-21
                 CC|                            |jakub at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Reduced testcase:

int v;

long __attribute__ ((noinline))
test (long *x, int y)
{
  int i;
  long s = 1;
  for (i = 0; i < y; i++)
    if (__builtin_mul_overflow (s, x[i], &s))
      v++;
  return s;
}

int
main ()
{
  long d[7] = { 975, 975, 975, 975, 975, 975, 975 };
  long r = test (d, 7);
  if (sizeof (long) * __CHAR_BIT__ == 64 && v != 1)
    __builtin_abort ();
  else if (sizeof (long) * __CHAR_BIT__ == 32 && v != 4)
    __builtin_abort ();
  return 0;
}

The problem is in VRP, the IMAGPART_EXPR of the MUL_OVERFLOW result is
processed with only some edges executable and others not, so the value ranges
of the values are only temporary, not final.  In that case, one of the
arguments of
MUL_OVERFLOW is assumed to be [1, 1] and the other argument is VARYING.
A final [1, 1] * VARYING in the same types is never overflowing though, the
result always fits into the type, so we set [0, 0] as the value range for the
IMAGPART_EXPR.  And for some reason we are not called again when the
MUL_OVERFLOW arguments are VARYING * VARYING.
So, is there some way how to tell VRP to simulate the IMAGPART_EXPR again?  Or
is there a way to see if the value ranges of the *_OVERFLOW arguments are just
temporary simulation or final?  Is the fact that IMAGPART_EXPR range might be
narrower initially and change to larger one later on compatible with VRP at
all?
Though, how is that generally different from say simulating s = s + 4 inside a
loop?  There we initially assume (if s is 1 before the loop) range [5, 5] and
later turn it into a wider range.  Though, for the IMAGPART_EXPR in this case,
the arguments of the MUL_OVERFLOW don't depend on the IMAGPART_EXPR value.

[Bug tree-optimization/64006] __builtin_mul_overflow fails to signal overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
          Component|middle-end                  |tree-optimization

[Bug tree-optimization/64006] __builtin_mul_overflow fails to signal overflow

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Fri Nov 21 20:41:37 2014
New Revision: 217945

URL: https://gcc.gnu.org/viewcvs?rev=217945&root=gcc&view=rev
Log:
    PR tree-optimization/64006
    * tree-vrp.c (stmt_interesting_for_vrp): Return true
    for {ADD,SUB,MUL}_OVERFLOW internal calls.
    (vrp_visit_assignment_or_call): For {ADD,SUB,MUL}_OVERFLOW
    internal calls, check if any REALPART_EXPR/IMAGPART_EXPR
    immediate uses would change their value ranges and return
    SSA_PROP_INTERESTING if so, or SSA_PROP_NOT_INTERESTING
    if there are some REALPART_EXPR/IMAGPART_EXPR immediate uses
    interesting for vrp.

    * gcc.c-torture/execute/pr64006.c: New test.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/pr64006.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vrp.c

[Bug tree-optimization/64006] __builtin_mul_overflow fails to signal overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.