Problem with VC++ signed and unsigned __int64 << and >> operators?

[Peter Bromley]

The following code snippet does not seem to work correcly

unsigned __int64 result = 0xFFFFFFFFFFFFF FFF;
result = result << 64;
Debugger.WriteL ine(System::Str ing::Format(S"{ 0:X16}", __box(result));
result = 0xFFFFFFFFFFFFF FFF;
result = result >> 64;
Debugger.WriteL ine(System::Str ing::Format(S"{ 0:X16}", __box(result));

__int64 result = -1;
result = result << 64;
Debugger.WriteL ine(System::Str ing::Format(S"{ 0:X16}", __box(result));

I am expecting output to read

000000000000000 0
FFFFFFFFFFFFFFF F
000000000000000 0
FFFFFFFFFFFFFFF F

but output reads

FFFFFFFF0000000 0 << incorrect
00000000FFFFFFF F << incorrect
FFFFFFFF0000000 0 << incorrect
FFFFFFFFFFFFFFF F << correct

All other shift values ( < 64) appear to work correctly.

Can someone from MS confirm this is a bug with the int64 shift
operators, please?

Peter

--
If you wish to reply to me directly, my addres is spam proofed as:

pbromley at adi dot co dot nz

Or if you prefer - no****@nowhere. com :-)

[Doug Harrison [MVP]]

Peter Bromley wrote:

The following code snippet does not seem to work correcly

unsigned __int64 result = 0xFFFFFFFFFFFFF FFF;
result = result << 64;
Debugger.Write Line(System::St ring::Format(S" {0:X16}", __box(result));
result = 0xFFFFFFFFFFFFF FFF;
result = result >> 64;
Debugger.Write Line(System::St ring::Format(S" {0:X16}", __box(result));

__int64 result = -1;
result = result << 64;
Debugger.Write Line(System::St ring::Format(S" {0:X16}", __box(result));

I am expecting output to read

00000000000000 00
FFFFFFFFFFFFFF FF
00000000000000 00
FFFFFFFFFFFFFF FF

but output reads

FFFFFFFF000000 00 << incorrect
00000000FFFFFF FF << incorrect
FFFFFFFF000000 00 << incorrect
FFFFFFFFFFFFFF FF << correct

All other shift values ( < 64) appear to work correctly.

It's undefined to shift a value by an amount >= its length in bits, so you
need to avoid doing that.

--
Doug Harrison
Microsoft MVP - Visual C++

[Gabest]

> It's undefined to shift a value by an amount >= its length in bits, so you

need to avoid doing that.

This thru for mc++ only, right? Shifting in x86 is well defined, for
unsigned 0s are shifted in, for signed the sign bit is extended when needed.
I wonder what can be the reason why the same code compiled for .net
shouldn't give the same results as its native counterpart.

[Gabest]

"Gabest" <ga****@freemai l.hu> wrote in message
news:e6******** ******@TK2MSFTN GP14.phx.gbl...

It's undefined to shift a value by an amount >= its length in bits, so
you
need to avoid doing that.

This thru

"is true" I mean. It's really late here :)

[Carl Daniel [VC++ MVP]]

Gabest wrote:

It's undefined to shift a value by an amount >= its length in bits,
so you need to avoid doing that.

This thru for mc++ only, right? Shifting in x86 is well defined, for
unsigned 0s are shifted in, for signed the sign bit is extended when
needed. I wonder what can be the reason why the same code compiled
for .net shouldn't give the same results as its native counterpart.

No, it's true for C and C++ in general - shifting by an amount >= the
variable size is undefined behavior according to the standards.

-cd

[Gabest]

Well, after digging up intel's manual on these shifting instructions, it is
defined but not in the way I though to be:

"The count operand can be an immediate value or register CL. The count is
masked to 5 bits, which limits the count range to 0 to 31"

I believe amd can have something similar for the x86-64 ISA in its manuals
too, and also that in 32 bit mode the compiler inserts such a piece of code
what still gives a good result for its builtin __int64 type, but only for
the native code.

[Doug Harrison [MVP]]

Gabest wrote:

It's undefined to shift a value by an amount >= its length in bits, so you
need to avoid doing that.

This thru for mc++ only, right? Shifting in x86 is well defined, for
unsigned 0s are shifted in, for signed the sign bit is extended when needed.
I wonder what can be the reason why the same code compiled for .net
shouldn't give the same results as its native counterpart.

What I said comes from the C++ Standard, 5.8/1. (To be completely accurate,
s/value/promoted left operand/, but note that a 64-bit integer undergoes no
promotion in VC++.) The VC docs say the same thing:

http://msdn.microsoft.com/library/de..._operators.asp
<q>
The results are undefined if the right operand of a shift expression is
negative or if the right operand is greater than or equal to the number of
bits in the (promoted) left operand.
</q>

I'm unable to find any information on the shift operators in MC++, but even
if the result were well-defined, I'd hesitate to take advantage of it.

--
Doug Harrison
Microsoft MVP - Visual C++

[Ioannis Vranos]

Gabest wrote:

This thru for mc++ only, right? Shifting in x86 is well defined, for
unsigned 0s are shifted in, for signed the sign bit is extended when needed.
I wonder what can be the reason why the same code compiled for .net
shouldn't give the same results as its native counterpart.

I suppose this happens because in managed applications you do not
program against your x86 but the .NET VM which has its own assembly
language etc.

So your x86 system-specific code does not work the same to this
different "machine".

To see detailed technical info for .NET (CLI) specific code, you may
download the latest CLI standard:

http://www.ecma-international.org/pu...s/Ecma-335.htm

which also contains the specification of its assembly language.
A book on this assembly language:

http://www.amazon.com/exec/obidos/tg...glance&s=books

--
Ioannis Vranos

[Hendrik Schober]

Gabest <ga****@freemai l.hu> wrote:

Well, after digging up intel's manual on these shifting instructions, it is
defined but not in the way I though to be:

"The count operand can be an immediate value or register CL. The count is
masked to 5 bits, which limits the count range to 0 to 31"

I believe amd can have something similar for the x86-64 ISA in its manuals
too, and also that in 32 bit mode the compiler inserts such a piece of code
what still gives a good result for its builtin __int64 type, but only for
the native code.

The problem is that you're not programming
in assembler/machine code. If you're in
C/C++/MC++ land, you have to follow the
rules as spelled out there. For C++ (and
most likely for C, too), what you do is
undefined. As for MC++ -- I don't know
that.

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett

[Gabest]

> The problem is that you're not programming

in assembler/machine code.
Yea, you are right, I was believing too much that the compiler would just
use the existing assembly instructions for shifting, while it has the right
to translate it to anything else of course.

There is still one thing but bothers me though. This means you cannot be
sure about shifting by a+b always gives the same result as shifting by a and
then b separately. Something like saying 1+2+3 equals to 6, but the result
of 1+5 is undefined. I can understand shl/shr/sar can have some limitations,
since they are just low level instructions translated directly to machine
code, but in c/c++ this sounds pretty wierd to me.
If you're in
C/C++/MC++ land, you have to follow the
rules as spelled out there. For C++ (and
most likely for C, too), what you do is
undefined. As for MC++ -- I don't know
that.

Schobi