[Bug c/55967] New: rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset

[Bug c/55967] New: rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset

[b1262178 at rmqkr dot net]

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

             Bug #: 55967
           Summary: rightshift an unsigned value (X) by it's number of
                    bits does not always yield 0, when X is an unsigned
                    that's leftshifted by it's number of bits and offset
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: b1262178@rmqkr.net


Hi,

I'm curring gcc via MinGW on a 32 bit PC:

The output of the following 

/********************************************/
#include <stdio.h>

int main(void)
{
  printf("%lu\n",  ((1U<<(32))));
  printf("%lu\n",  ((1U<<(32))) + 0x80000000U);

  printf("%lu\n", (((1U<<(32))) + 0x80000000U) >> 32U); /* expecting 0 but get
0x80000000U instead. BUG???? */
  printf("%lu\n", (               0x80000000U) >> 32U); /* compare: here
correctly get 0! */
  printf("%lu\n", (((1U<<(32)))              ) >> 32U); /* compare: here
correctly get 0! */
  return 0;

  return 0;
}
/********************************************/

is:

0
2147483648
2147483648 // Bug!
0
0

THE 3rd output line IS A BUG, right? I expect to get 0.
And why do I expect 0. Because I've got a 32-bit number and rightshift it by
32.

Ouput lines 4 and 5 do that correctly: they yield 0.

So what's going on in line 3 ?






gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32
--prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)


Thanks.

[Bug c/55967] rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset

[b1262178 at rmqkr dot net]

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

--- Comment #1 from JoeSoe <b1262178 at rmqkr dot net> 2013-01-14 12:53:24 UTC ---
Of course I get warnings... 
go.c:146:3: warning: left shift count >= width of type [enabled by default]
go.c:146:3: warning: right shift count >= width of type [enabled by default]

And of course ((1U<<(32))) is also undefined behaviour, since the
www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf#page=578 states on undefined
behaviour:

An expression is shifted by a negative number or by an amount greater than or
equal to the width of the promoted expression (6.5.7).


Bit even if this is undefined behaviour, I would like gcc to handle this
gracefully, as is the case with 
(((1U<<(32)))              ) >> 32U

which "gracefully" yields 0.


So the following should also do the graceful thing and yield 0, right?
((1U<<(32))) + 0x80000000U) >> 32U

[Bug c/55967] rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-14 13:02:12 UTC ---
The testcase is invalid, the bug is only on the side of the testcase.

[Bug c/55967] rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset

[b1314361 at rmqkr dot net]

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

JoeSoe <b1314361 at rmqkr dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b1314361 at rmqkr dot net

--- Comment #3 from JoeSoe <b1314361 at rmqkr dot net> 2013-01-15 07:15:41 UTC ---
Hi Jakub Jelinek,

can you elaborate?
What does it mean to say: "The testcase is invalid, the bug is only on the side
of the testcase." ?

Why does gcc not yield the "graceful/expected" result, and why will no effort
be undertaken to make it yield the "graceful/expected" result?

For example: Is it because of optimizations, that would be removed, if it were
to yield the "graceful/expected" result??

In other words: what's the background on this?
Thanks.

[Bug c/55967] rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-15 07:55:06 UTC ---
Please google around on "undefined behavior", you'll find various FAQs about
it.  When a program triggers undefined behavior, anything can happen, the
compiler can optimize based on the fact that such behavior won't happen in a
program, as a bonus in this case you get a warning telling you your bug.  There
is no graceful/expected behavior for undefined behavior, otherwise it wouldn't
be undefined.

[Bug c/55967] rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> 2013-01-15 16:38:36 UTC ---
Note that clang has -fsanitize=shift which produces a runtime message every
time a >> is executed with an out of bounds argument.