[Bug c/36402] New: -0x80000000 (INT_MIN) erroneously treated as unsigned

[Bug c/36402] New: -0x80000000 (INT_MIN) erroneously treated as unsigned

[gcczilla at achurch dot org]

GCC seems to treat the 32-bit integer constant -0x80000000 (INT_MIN) as an
unsigned value, when it should be signed.  (I don't think this is a duplicate
of bug 25329, since I'm not trying to negate the constant.)  For example:

int a = 1;
int foo(void)
{
    return -0x80000000 < a;
}

improperly returns 0, even though -0x80000000 is less than any positive value. 
>From the assembly output, it seems as though GCC is treating -0x80000000 as an
unsigned value (using the unsigned "seta" instruction to interpret the
comparison result):

        movl    a, %eax
        cmpl    $-2147483648, %eax
        seta    %al

Changing the comparison to:
    return (int)-0x80000000 < a;  // Cast to signed
succeeds, as expected (interestingly using "setne" rather than "setg", though
certainly either works).


-- 
           Summary: -0x80000000 (INT_MIN) erroneously treated as unsigned
           Product: gcc
           Version: 4.2.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gcczilla at achurch dot org


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

[Bug c/36402] -0x80000000 (INT_MIN) erroneously treated as unsigned

[ebotcazou at gcc dot gnu dot org]

------- Comment #1 from ebotcazou at gcc dot gnu dot org  2008-05-31 19:50 -------
> GCC seems to treat the 32-bit integer constant -0x80000000 (INT_MIN) as an
> unsigned value, when it should be signed.

Incorrect.  -0x80000000 is not an integer constant, it's the negation of the
integer constant 0x80000000, which is unsigned (C99 6.4.4.1).


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug c/36402] -0x80000000 (INT_MIN) erroneously treated as unsigned

[gcczilla at achurch dot org]

------- Comment #2 from gcczilla at achurch dot org  2008-06-01 04:17 -------
Fair enough, but GCC's documentation explicitly says (gcc.info section 4.5):

   * `Whether signed integer types are represented using sign and
     magnitude, two's complement, or one's complement, and whether the
     extraordinary value is a trap representation or an ordinary value
     (C99 6.2.6.2).'

     GCC supports only two's complement integer types, and all bit
     patterns are ordinary values.

Given that, I think a typical user would assume (as I have) that GCC would
treat -0x80000000 as the signed value -2^31; otherwise there would seem to be
no way to write a single constant to represent that valid value.  So I'm going
to have to argue that this is still a bug, whether in the documentation or in
the compiler itself.


-- 

gcczilla at achurch dot org changed:

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


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

[Bug c/36402] -0x80000000 (INT_MIN) erroneously treated as unsigned

[ebotcazou at gcc dot gnu dot org]

------- Comment #3 from ebotcazou at gcc dot gnu dot org  2008-06-01 07:25 -------
> Given that, I think a typical user would assume (as I have) that GCC would
> treat -0x80000000 as the signed value -2^31; otherwise there would seem to be
> no way to write a single constant to represent that valid value.

You're confusing the internal representation, described by the paragraph you
quoted, and the syntax of literals.  There is no bug in this case, it's the
well-know limitation of C whereby you need to write INT_MIN as (-INT_MAX - 1).


-- 

ebotcazou at gcc dot gnu dot org changed:

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


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

[Bug c/36402] -0x80000000 (INT_MIN) erroneously treated as unsigned

[joseph at codesourcery dot com]

------- Comment #4 from joseph at codesourcery dot com  2008-06-01 12:22 -------
Subject: Re:  -0x80000000 (INT_MIN) erroneously treated as
 unsigned

On Sun, 1 Jun 2008, gcczilla at achurch dot org wrote:

> Fair enough, but GCC's documentation explicitly says (gcc.info section 4.5):

It also explicitly explains, in the section "Incompatibilities", that 
-2147483648 is positive, and why.  (In C99 mode, 2147483648 becomes of 
type long long, but 0x80000000 is still unsigned.)


-- 


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

[Bug c/36402] -0x80000000 (INT_MIN, -2147483648) treated as unsigned

[gcczilla at achurch dot org]

------- Comment #5 from gcczilla at achurch dot org  2008-06-01 13:59 -------
Thanks for the clarification.  (To be honest, I wouldn't have thought to look
in the "Incompatibilities" section--I haven't touched a non-ANSI compiler for
over a decade--but either way I guess it's my fault for not searching for
"2147483648".)

Touched up the summary line a bit to help future searchers.


-- 

gcczilla at achurch dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|-0x80000000 (INT_MIN)       |-0x80000000 (INT_MIN, -
                   |erroneously treated as      |2147483648) treated as
                   |unsigned                    |unsigned


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