[Bug c/56956] New: ftrapv traps on valid abs-like code

[Bug c/56956] New: ftrapv traps on valid abs-like code

[sunfish at google dot com]

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

             Bug #: 56956
           Summary: ftrapv traps on valid abs-like code
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: sunfish@google.com


This program aborts when compiled with -ftrapv, despite not having any
overflow:

#include <limits.h>
#include <inttypes.h>
#include <stdio.h>

__attribute__((noinline))
uint64_t foo(uint64_t x) {
  return x <= INT64_MAX ? x : -x;
}

int main() {
  uint64_t n = foo((uint64_t)INT64_MIN);
  printf("%" PRIx64 "\n", n);
  return 0;
}

It appears that the code in foo is being folded into an absolute-value
expression which does not work properly on INT64_MIN. However, the code as
written does  handle INT64_MIN without any signed overflow.

[Bug c/56956] ftrapv traps on valid abs-like code

[jasonwucj at gmail dot com]

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

Chung-Ju Wu <jasonwucj at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jasonwucj at gmail dot com

--- Comment #1 from Chung-Ju Wu <jasonwucj at gmail dot com> 2013-04-15 00:58:14 UTC ---
I think 'x' can not present negative value.

[Bug c/56956] ftrapv traps on valid abs-like code

[sunfish at google dot com]

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

--- Comment #2 from Dan Gohman <sunfish at google dot com> 2013-04-15 03:53:10 UTC ---
(In reply to comment #1)
> I think 'x' can not present negative value.

The unary minus operator is defined for unsigned types. It doesn't produce
signed overflow.

[Bug c/56956] ftrapv traps on valid abs-like code

[sunfish at google dot com]

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

--- Comment #3 from Dan Gohman <sunfish at google dot com> 2013-04-15 03:54:32 UTC ---
Pulling the unary minus out into a separate statement, like this:

  uint64_t y = -x;
  return x <= INT64_MAX ? x : -y;

causes the program to execute correctly.

[Bug c/56956] ftrapv traps on valid abs-like code

[jasonwucj at gmail dot com]

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

--- Comment #4 from Chung-Ju Wu <jasonwucj at gmail dot com> 2013-04-15 04:18:13 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > I think 'x' can not present negative value.
> 
> The unary minus operator is defined for unsigned types. It doesn't produce
> signed overflow.

According to C99 6.5.3.3 Point 3 and C99 6.5 Point 5:

"The result of the unary '-' operator is the negative of its operand."

"... if the result is ... not in the range of representable
 values for its type... the behavior is undefined."

So my understanding is that the evaluation expression '-x' is not
a representable value of 'uint64_t', which is undefined behavior,
resulting abort if -ftrav is issued.

Perhaps my understanding is incorrect? :(

[Bug c/56956] ftrapv traps on valid abs-like code

[sunfish at google dot com]

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

--- Comment #5 from Dan Gohman <sunfish at google dot com> 2013-04-15 05:12:30 UTC ---
(In reply to comment #4)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > I think 'x' can not present negative value.
> > 
> > The unary minus operator is defined for unsigned types. It doesn't produce
> > signed overflow.
> 
> According to C99 6.5.3.3 Point 3 and C99 6.5 Point 5:
> 
> "The result of the unary '-' operator is the negative of its operand."
> 
> "... if the result is ... not in the range of representable
>  values for its type... the behavior is undefined."
> 
> So my understanding is that the evaluation expression '-x' is not
> a representable value of 'uint64_t', which is undefined behavior,
> resulting abort if -ftrav is issued.
> 
> Perhaps my understanding is incorrect? :(

Yes; unsigned types are an exception to the rule:

C99 6.2.5p9 says "A computation involving unsigned operands can never overflow,
because a result that cannot be represented by the resulting unsigned integer
type is reduced modulo the number that is one greater than the largest value
that can be represented by the resulting type."

The wording is a little vague, but it means that negative results are converted
to unsigned values by conceptually adding the maximum unsigned value plus one
until the value is in range.
>From gcc-bugs-return-420283-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 15 05:14:31 2013
Return-Path: <gcc-bugs-return-420283-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28111 invoked by alias); 15 Apr 2013 05:14:31 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28085 invoked by uid 48); 15 Apr 2013 05:14:27 -0000
From: "sunfish at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/56956] ftrapv traps on valid abs-like code
Date: Mon, 15 Apr 2013 05:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sunfish at google dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56956-4-cc4NYyH3hH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56956-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56956-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01428.txt.bz2
Content-length: 491


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV956

--- Comment #6 from Dan Gohman <sunfish at google dot com> 2013-04-15 05:14:27 UTC ---
(In reply to comment #3)
> Pulling the unary minus out into a separate statement, like this:
>
>   uint64_t y = -x;
>   return x <= INT64_MAX ? x : -y;
>
> causes the program to execute correctly.

Actually, I meant to write this:

  uint64_t y = -x;
  return x <= INT64_MAX ? x : y;

and it still executes correctly, with no trap.

[Bug c/56956] ftrapv traps on valid abs-like code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-10-22
                 CC|                            |mpolacek at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed. 

#define INT_MIN (-__INT_MAX__ - 1L)

unsigned int
foo (unsigned int x)
{
  return x <= __INT_MAX__ ? x : -x;
}

int
main ()
{
  return foo (INT_MIN);
}

We transform foo to
return (unsigned int) ABS_EXPR <(signed int) x>;

[Bug c/56956] ftrapv traps on valid abs-like code

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yeah, unfortunately that doesn't look correct :(

I've always wanted to have an ABS_EXPR variant that returns an unsigned value
(so with no undefined behavior).  Maybe just overload ABS_EXPR in this way.
You'd need to assure expansion doesn't use absv optabs, that is, trapping
behavior / undefinedness would depend on the ABS_EXPR result type.  The
argument type would still be signed.

[Bug middle-end/56956] ftrapv traps on valid abs-like code

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.

[Bug middle-end/56956] ftrapv traps on valid abs-like code

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Oct 29 08:21:50 2015
New Revision: 229517

URL: https://gcc.gnu.org/viewcvs?rev=229517&root=gcc&view=rev
Log:
2015-10-29  Richard Biener  <rguenther@suse.de>

        PR middle-end/56956
        * fold-const.c (fold_cond_expr_with_comparison): Do not fold
        unsigned conditonal negation to ABS_EXPR.

        * c-c++-common/ubsan/pr56956.c: New testcase.

Added:
    trunk/gcc/testsuite/c-c++-common/ubsan/pr56956.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fold-const.c
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/56956] [4.9/5 Regression] ftrapv traps on valid abs-like code

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |3.4.6, 6.0
   Target Milestone|---                         |4.9.4
            Summary|ftrapv traps on valid       |[4.9/5 Regression] ftrapv
                   |abs-like code               |traps on valid abs-like
                   |                            |code
      Known to fail|6.0                         |4.0.0, 4.3.3, 4.5.2

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.