[Bug rtl-optimization/68131] New: missed optimization and warning for broken overflow check

[Bug rtl-optimization/68131] New: missed optimization and warning for broken overflow check

[rv at rasmusvillemoes dot dk]

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

            Bug ID: 68131
           Summary: missed optimization and warning for broken overflow
                    check
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rv at rasmusvillemoes dot dk
  Target Milestone: ---

Using "a + b < a" is the standard (and well-defined) way of checking for
overflow when adding unsigned variables a,b. However, due to promotion rules,
this breaks down when a and b have type narrower than int. Consider

struct s {
        unsigned short x;
};

int f(struct s *a, const struct s *b)
{
        if (a->x + b->x < a->x)
                return -1;
        a->x += b->x;
        return 0;
}

The conditional is never true, but neither clang or gcc warns (with -Wall
-Wextra) about what was obviously intended to be an overflow check. clang does
compile this to

   0:   66 8b 06                mov    (%rsi),%ax
   3:   66 01 07                add    %ax,(%rdi)
   6:   31 c0                   xor    %eax,%eax
   8:   c3                      retq   

whereas gcc generates

   0:   0f b7 0f                movzwl (%rdi),%ecx
   3:   0f b7 16                movzwl (%rsi),%edx
   6:   89 d0                   mov    %edx,%eax
   8:   01 ca                   add    %ecx,%edx
   a:   39 d1                   cmp    %edx,%ecx
   c:   7f 12                   jg     20 <f+0x20>
   e:   01 c8                   add    %ecx,%eax
  10:   66 89 07                mov    %ax,(%rdi)
  13:   31 c0                   xor    %eax,%eax
  15:   c3                      retq   
  16:   66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  1d:   00 00 00 
  20:   b8 ff ff ff ff          mov    $0xffffffff,%eax
  25:   c3                      retq

[Bug tree-optimization/68131] missed optimization and warning for broken overflow check

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-10-28
          Component|rtl-optimization            |tree-optimization
     Ever confirmed|0                           |1

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
(in type int)
  _10 = _6 + _9;
  if (_6 > _10)

Indeed we fail to simplify that for some reason. If we did simplify, it might
print one of those "assuming signed overflow does not occur when assuming that
(X + c) < X is always false" warnings.

[Bug tree-optimization/68131] missed optimization and warning for broken overflow check

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We indeed do not have this optimization, only A + CST CMP CST to A CMP CST'
and related.  Note that _9 might be negative so we also need range info
for this.  VRPs symbolic range stuff isn't good enough to simplify this.

[Bug tree-optimization/68131] missed optimization and warning for broken overflow check

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> We indeed do not have this optimization, only A + CST CMP CST to A CMP CST'
> and related.  Note that _9 might be negative so we also need range info
> for this.  VRPs symbolic range stuff isn't good enough to simplify this.

If we want to simplify directly to false, I would expect a match.pd pattern
using tree_expr_nonnegative_p to work in this case (conversion from a smaller
unsigned). By the way, maybe tree_single_nonnegative_warnv_p could try looking
at get_range_info before forwarding to gimple_stmt_nonnegative_warnv_p.

But the much simpler transformation: a+b<a => b<0 does not require any VRP info
and would let the next VRP pass finish the work.

[Bug tree-optimization/68131] missed optimization and warning for broken overflow check

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |8.0
      Known to work|                            |8.1.0
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
      Known to fail|                            |7.5.0

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed by r8-3771.

There is no overflow here as unsigned short gets prompted to int and such.

[Bug tree-optimization/68131] missed optimization and warning for broken overflow check

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #3)
> (In reply to Richard Biener from comment #2)
> > We indeed do not have this optimization, only A + CST CMP CST to A CMP CST'
> > and related.  Note that _9 might be negative so we also need range info
> > for this.  VRPs symbolic range stuff isn't good enough to simplify this.
> 
> If we want to simplify directly to false, I would expect a match.pd pattern
> using tree_expr_nonnegative_p to work in this case (conversion from a
> smaller unsigned). By the way, maybe tree_single_nonnegative_warnv_p could
> try looking at get_range_info before forwarding to
> gimple_stmt_nonnegative_warnv_p.

Oh I filed PR 111959 (and will be submitting a patch later today) for that.