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

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
>
>
>

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

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

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.

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.

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.

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.