[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|arm-elf-gcc                 |arm-elf-gcc,x86
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-29
                 CC|                            |gjl at gcc dot gnu.org
      Known to work|                            |3.4.5
            Version|4.3.2                       |4.8.2
     Ever confirmed|0                           |1
      Known to fail|                            |4.8.2

--- Comment #10 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
This is still present for 4.8.2 and current trunk (future 4.9.0).

C++ works fine, i.e. just the warnings that I'd expect.

As this works as expected in good old 3.4.x, shouldn't this be marked as
regression?

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So this has been fixed on all of the active branches. Since PR 107465 was the
one recorded in the changelog, closing as a dup of that one.

*** This bug has been marked as a duplicate of bug 107465 ***

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[wolter.hellmundvega at tevva dot com]

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

wolter.hellmundvega at tevva dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wolter.hellmundvega at tevva dot c
                   |                            |om

--- Comment #14 from wolter.hellmundvega at tevva dot com ---
I'm not sure this is fixed, please correct me if wrong, but

    #include <stdio.h>
    #include <stdint.h>

    int main(void)
    {
        const uint8_t u = 0U;
        const uint8_t y = (uint8_t) ~u;

        return ((uint8_t) u != (uint8_t) ~y);
    }

gives warning

    test.c: In function ‘main’:
    test.c:9:25: warning: comparison of promoted bitwise complement of an
unsigned value with unsigned [-Wsign-compare]
        9 |     return ((uint8_t) u != (uint8_t) ~y);
          |                         ^~

Does this not mean that this issue is still present?

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[michael dot malone at tait dot co dot nz]

------- Comment #9 from michael dot malone at tait dot co dot nz  2009-02-24 00:43 -------
I forgot to mention, if you assign to an intermediate variable, the warning
also disappears which is the behaviour I would expect from an explicit cast.


-- 

michael dot malone at tait dot co dot nz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael dot malone at tait
                   |                            |dot co dot nz


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

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[michael dot malone at tait dot co dot nz]

------- Comment #8 from michael dot malone at tait dot co dot nz  2009-02-24 00:40 -------
#ifdef UINT
  #include <stdint.h>
  #define TYPE uint16_t
#else
  #define TYPE unsigned short int
#endif

#define VALUE 0xFF

int main(void);

int main() {
   TYPE variable_a = ~VALUE;
   TYPE variable_b = VALUE;
   TYPE result;

   #ifdef ASSIGN
   TYPE tmp = ~variable_a;
   result = (variable_b == tmp);
   #else
   result = (variable_b == (TYPE) ~variable_a);
   #endif

   return 0;
}

Further to John's input, here is a sample program which shows up why this bug
is interesting.  When one uses a typedef'd type, the promoted comparison
warning is displayed.  When one does not, it isn't!

This is not the case for gcc-4.2.3 -both variants compile without warnings.

The compile commands I used were:
gcc gcc_bug.c -W -Wall -o bug
and
gcc gcc_bug.c -W -Wall -DUINT -o bug


-- 


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

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[john dot carter at tait dot co dot nz]

------- Comment #7 from john dot carter at tait dot co dot nz  2009-02-23 23:53 -------
R Guenther said...
>  (int)u1 == (int)(u8_t)(~(int)u2)
>
>  that we do not warn for the first case is because it is optimized to
>    u1 == ~u2 before.
>
>   Why do you think the warning is incorrect?
-----------------------------------------------

I would expect 

  u2 to be promoted to a 4 byte int

  ~ to do the ones complement on a 4 byte int

  (unsigned char)~u2 to truncate to one byte discarding the most significant 3
bytes

  and then the result get promoted to an int to evaluate the ==

ie. The cast cannot get optimized away, it's not a null op, it discards the
most significant bytes. 

ie. (int)(unsigned char)~(int)u2 is not equivalent to
    ~(int)u2

ie. This is a bug


-- 


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

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2008-12-02 12:12 -------
*** Bug 38370 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doko at ubuntu dot com


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

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[fredrik dot hederstierna at securitas-direct dot com]

------- Comment #5 from fredrik dot hederstierna at securitas-direct dot com  2008-12-01 13:35 -------
On Intel i386-GCC (4.2.3) we just get warning only for the line

  if (c1 == ~c2)

The other lines does not give warnings, so maybe its just the ARM-backend that
catch this warning.

I guess you mean that for ARM target the optimization tree does things that
silence the warning. Is it good that optimizations can silence possible
warnings/errors? And that it differs depending on which backend I'm running?


-- 


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

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[fredrik dot hederstierna at securitas-direct dot com]

------- Comment #4 from fredrik dot hederstierna at securitas-direct dot com  2008-12-01 12:55 -------
Heres another example, then I do not think the warnings are due to
optimization.
I have same warnings with both -O0 and -O3.


#include <stdio.h>

typedef unsigned char u8_t;

void test_cast(unsigned char c1, unsigned char c2, u8_t u1, u8_t u2)
{
  if (c1 == (unsigned char)(~c2)) {
    printf("No warning");
  }
  if (c1 == ~c2) {
    printf("This gives warning");
  }
  if (u1 == (u8_t)(~u2)) {
    printf("This gives warning");
  }
  if ((unsigned char)u1 == (unsigned char)(~u2)) {
    printf("This gives warning");
  }
}


The original code that caused this warnings are the TCP/IP stack lwIP, then I
constructed this minimal example.

Original code from lwIP TCP/IP stack:
-------------------------------------

static u8_t ip_reassbitmap[IP_REASS_BUFSIZE / (8 * 8) + 1];
static const u8_t bitmap_bits[8] = { 0xff, 0x7f, 0x3f, 0x1f, 0x0f, 0x07, 0x03,
0x01 };

/.../
      if (ip_reassbitmap[ip_reasslen / (8 * 8)] !=
        (u8_t) ~ bitmap_bits[ip_reasslen / 8 & 7]) {
/.../


-- 


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

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2008-12-01 12:49 -------
As I said, for the first case we optimize away the promotions before the
warning
code comes along.


-- 


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

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[fredrik dot hederstierna at securitas-direct dot com]

------- Comment #2 from fredrik dot hederstierna at securitas-direct dot com  2008-12-01 12:40 -------
Then why dont we get warning on the first if-statement?
Shouldnt these lines be equal?

  if (c1 == (unsigned char)(~c2)) {
  }
  if (u1 == (u8_t)(~u2)) {  // THIS WILL GIVE WARNING
  }

The first if-statement does not give warnings, should this be evaluated the
same way?

if ((int)c1 == (int)(unsigned char)(~(int)c2)) {

My idea was that either of the if-statements are wrong. Either both or none
should give warnings, or am I wrong? The typedef to "unsigned char" should be
the same as using primitive types regarding this warning, or?


-- 


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

[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-12-01 10:01 -------
  /* Warn if two unsigned values are being compared in a size larger
     than their original size, and one (and only one) is the result of
     a `~' operator.  This comparison will always fail.

     Also warn if one operand is a constant, and the constant does not
     have all bits set that are set in the ~ operand when it is
     extended.  */

note that integer promotion is done on the operand(!) of ~.  So u1 ==
(u8_t)(~u2)
is equal to

   (int)u1 == (int)(u8_t)(~(int)u2)

that we do not warn for the first case is because it is optimized to
u1 == ~u2 before.

Why do you think the warning is incorrect?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic


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