www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Bug in shifting

reply Michelle Long <HappyDance321 gmail.com> writes:
byte x = 0xF;
ulong y = x >> 60;

Does not compute the proper value.

It seems that the shift amount is wrapped. My code is more 
complex. The code above does give an error. I am using the code 
in a template. If I change x to ulong it works as expected.

I've noticed the compiler is not throwing up errors and warnings 
like it used to:

I thought D required breaks for cases? Seems it doesn't any 
longer! I'm only using -g -gf -d


DMD64 D Compiler v2.083.0
Dec 13 2018
next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
I do not understand you?
What is wrong? It works ok.
https://run.dlang.io/is/ZFf0FQ

What do you mean by D required breaks for cases?

On Fri, Dec 14, 2018 at 1:20 AM Michelle Long via Digitalmars-d-learn <
digitalmars-d-learn puremagic.com> wrote:

 byte x = 0xF;
 ulong y = x >> 60;

 Does not compute the proper value.

 It seems that the shift amount is wrapped. My code is more
 complex. The code above does give an error. I am using the code
 in a template. If I change x to ulong it works as expected.

 I've noticed the compiler is not throwing up errors and warnings
 like it used to:

 I thought D required breaks for cases? Seems it doesn't any
 longer! I'm only using -g -gf -d


 DMD64 D Compiler v2.083.0
Dec 13 2018
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/13/18 7:16 PM, Michelle Long wrote:
 byte x = 0xF;
 ulong y = x >> 60;
Surely you meant x << 60? As x >> 60 is going to be 0, even with a ulong.
 
 Does not compute the proper value.
 
 It seems that the shift amount is wrapped. My code is more complex. The 
 code above does give an error. I am using the code in a template. If I 
 change x to ulong it works as expected.
Given that your code above doesn't compile, it's hard to figure out what you mean. Do you have a working example?
 I've noticed the compiler is not throwing up errors and warnings like it 
 used to:
 
 I thought D required breaks for cases? Seems it doesn't any longer! I'm 
 only using -g -gf -d
It doesn't require breaks for cases, it requires no fall-through on cases. Again, an example would help describe what you mean. -Steve
Dec 13 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, December 13, 2018 6:56:33 PM MST Steven Schveighoffer via 
Digitalmars-d-learn wrote:
 On 12/13/18 7:16 PM, Michelle Long wrote:
 I've noticed the compiler is not throwing up errors and warnings like it
 used to:

 I thought D required breaks for cases? Seems it doesn't any longer! I'm
 only using -g -gf -d
It doesn't require breaks for cases, it requires no fall-through on cases. Again, an example would help describe what you mean.
Well, to be more precise, it doesn't allow fallthrough when the case statement contains code. It will allow it when it doesn't. e.g. case 0: case 1: break; is perfectly legal. However, when the case statement contains code, then yeah, some form of control statement is required to exit the case statement, but that's a lot more than just break. continue, goto, return, etc. can all be used to exit a case statement. Any control statement that explicitly exits the case statement will work. And of course, goto case can be used for explicit fallthrough. - Jonathan M Davis
Dec 13 2018
parent Michelle Long <HappyDance321 gmail.com> writes:
On Friday, 14 December 2018 at 02:17:20 UTC, Jonathan M Davis 
wrote:
 On Thursday, December 13, 2018 6:56:33 PM MST Steven 
 Schveighoffer via Digitalmars-d-learn wrote:
 On 12/13/18 7:16 PM, Michelle Long wrote:
 I've noticed the compiler is not throwing up errors and 
 warnings like it used to:

 I thought D required breaks for cases? Seems it doesn't any 
 longer! I'm only using -g -gf -d
It doesn't require breaks for cases, it requires no fall-through on cases. Again, an example would help describe what you mean.
Well, to be more precise, it doesn't allow fallthrough when the case statement contains code. It will allow it when it doesn't. e.g. case 0: case 1: break; is perfectly legal. However, when the case statement contains code, then yeah, some form of control statement is required to exit the case statement, but that's a lot more than just break. continue, goto, return, etc. can all be used to exit a case statement. Any control statement that explicitly exits the case statement will work. And of course, goto case can be used for explicit fallthrough. - Jonathan M Davis
I thought I had code in it which is what struct me as odd. There is a good chance I was wrong about this though since I was adding a bunch of case statements and code. Given that this occurred with the other problem might correlate to something else. Not that big a yet but the first struck me as a big problem if it is a bug... having code that should error but passes and provides wrong calculations is very prone to producing major bugs in a program. I don't feel like trying to reproduce them, but if they crop up again I'll try and catch them.
Dec 13 2018
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 14/12/2018 02:56, Steven Schveighoffer wrote:
 On 12/13/18 7:16 PM, Michelle Long wrote:
 byte x = 0xF;
 ulong y = x >> 60;
Surely you meant x << 60? As x >> 60 is going to be 0, even with a ulong.
It doesn't work as intuitive as you'd expect: void main() { int x = 256; int y = 36; int z = x >> y; writeln(z); } prints "16" without optimizations and "0" with optimizations. This happens for x86 architecture because the processor just uses the lower bits of the shift count. It is probably the reason why the language disallows shifting by more bits than the size of the operand.
Dec 18 2018
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 18 December 2018 at 20:33:43 UTC, Rainer Schuetze 
wrote:
 On 14/12/2018 02:56, Steven Schveighoffer wrote:
 On 12/13/18 7:16 PM, Michelle Long wrote:
 byte x = 0xF;
 ulong y = x >> 60;
Surely you meant x << 60? As x >> 60 is going to be 0, even with a ulong.
It doesn't work as intuitive as you'd expect: void main() { int x = 256; int y = 36; int z = x >> y; writeln(z); } prints "16" without optimizations and "0" with optimizations. This happens for x86 architecture because the processor just uses the lower bits of the shift count. It is probably the reason why the language disallows shifting by more bits than the size of the operand.
Yes. On x86 shifting (x >> y) is in reality x >> (y & 0x1F) on 32 bits and x >> (y & 0x3F) on 64 bits.
Dec 19 2018
prev sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Fri, 14 Dec 2018 00:16:51 +0000, Michelle Long wrote:
 byte x = 0xF;
 ulong y = x >> 60;
"Error: shift by 60 is outside the range 0..31" This is the result of integer promotion rules. Change the 30 to a 60 and it works, and the result is, as you would expect, 0.
 I thought D required breaks for cases? Seems it doesn't any longer!
A number of things can terminate a case block: * break * continue * goto * assert * throw * return Probably a few others.
Dec 13 2018