[Bug tree-optimization/54014] New: Value Range propagation bug

[Bug tree-optimization/54014] New: Value Range propagation bug

[ferrandi at elet dot polimi.it]

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

             Bug #: 54014
           Summary: Value Range propagation bug
    Classification: Unclassified
           Product: gcc
           Version: 4.5.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ferrandi@elet.polimi.it


Created attachment 27822
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27822
sightly modified version of arith-rand.c

Dears,

I've found a problem with a sightly modified version of a gcc regression test
(arith-rand.c).
The regression test has been modified in order to abort on a specific
condition. The test correctly aborts when no optimization is performed but it
does not fail when -O2 is passed. The problem seems to be in how the VRP work,
in fact once the -fno-tree-vrp is passed the test correctly fails.

The line I've added to arith-rand.c is the following

if((unsigned int) ABS (yy)==2147483648u) abort();

The VRP claims that (unsigned int) ABS (yy) is in the range [1, 2147483647] but
the actual range should be [1, 2147483648]. Everything seems to be related to
the managing of -(-2147483648).

The test does not abort on these versions on gcc-4.5.3 (Ubuntu 12.04), 4.6.3
(Ubuntu 12.04) and on gcc-4.7.1 (debian wheezy/sid) with the following command
line:

gcc-4.5 arith-rand.c   -O2 #(Ubuntu 12.04)
gcc-4.5 arith-rand.c   -O2 #(Ubuntu 12.04)
gcc-4.7 arith-rand.c  -O2 #(debian wheezy/sid)

while it correctly aborts once the option -fno-tree-vrp is passed

Cheers,

Fabrizio

[Bug tree-optimization/54014] Value Range propagation bug

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-18 11:44:26 UTC ---
The VRP claims that (unsigned int) ABS (yy) is in the range [1, 2147483647] but
the actual range should be [1, 2147483648]. Everything seems to be related to
the managing of -(-2147483648).

abs () on an int is in the range [0, 2147483647], converting that to
unsigned does not increase that range.  You probably want a ABSU function
which returns an unsigned number - but that does not exist.

[Bug tree-optimization/54014] Value Range propagation bug

[ferrandi at elet dot polimi.it]

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

--- Comment #2 from Fabrizio Ferrandi <ferrandi at elet dot polimi.it> 2012-07-18 11:56:26 UTC ---
I do not agree.
abs(-2147483648) returns -2147483648.

May be is odd but is how the implementation of abs works. Isn't it?

[Bug tree-optimization/54014] Value Range propagation bug

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-18 12:21:06 UTC ---
(In reply to comment #2)
> I do not agree.
> abs(-2147483648) returns -2147483648.
> 
> May be is odd but is how the implementation of abs works. Isn't it?

abs(-2147483648) invokes undefined behavior, similar to -(-2147483648),
according to the C standard.

[Bug tree-optimization/54014] Value Range propagation bug

[ferrandi at elet dot polimi.it]

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

--- Comment #4 from Fabrizio Ferrandi <ferrandi at elet dot polimi.it> 2012-07-18 17:41:48 UTC ---
Maybe I missing something but there is a specific code that deals with this
undefined behavior in tree-vrp.c:

  else if (code == ABS_EXPR
           && !TYPE_UNSIGNED (type))
    {
      /* -TYPE_MIN_VALUE = TYPE_MIN_VALUE with flag_wrapv so we can't get a
         useful range.  */
      if (!TYPE_OVERFLOW_UNDEFINED (type)
      && ((vr0.type == VR_RANGE
           && vrp_val_is_min (vr0.min))
          || (vr0.type == VR_ANTI_RANGE
          && !vrp_val_is_min (vr0.min)
          && !range_includes_zero_p (&vr0))))
    {
      set_value_range_to_varying (vr);
      return;
    }

This code is from gcc 4.5.3 and it still survives in gcc 4.7.1. I've spent some
further time on this issues and it seems that the range does not come from abs
restriction. I will spend some further effort later.

[Bug tree-optimization/54014] Value Range propagation bug

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-07-19 07:49:45 UTC ---
But you aren't compiling with -fwrapv, are you?  If you were, it would be
defined (as a C standard extension) to what you are expecting.

[Bug tree-optimization/54014] Value Range propagation bug

[ferrandi at elet dot polimi.it]

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

--- Comment #6 from Fabrizio Ferrandi <ferrandi at elet dot polimi.it> 2012-07-19 09:11:31 UTC ---
Yes, you are right. I'm assuming a two complements arithmetic but without
passing the -fwrapv parameter. With that parameter my analysis is starting to
get correct results. I'm working on a Verilog backend based on gcc IR.
Thanks for your hints!