phobos's circle CI runs a busted version of DMD
jmh530
john.michael.hall at gmail.com
Wed Jan 11 13:51:43 UTC 2023
On Wednesday, 11 January 2023 at 13:26:57 UTC, Dukc wrote:
> On Wednesday, 11 January 2023 at 01:03:33 UTC, deadalnix wrote:
>> Sample code:
>> ```d
>> ushort ee = 1028;
>> ee <<= 5U;
>> ee >>= 5U;
>> writeln(ee);
>> ```
>>
>> Regular compiler: https://godbolt.org/z/TcbjP76fW (prints 1028)
>> Circle CI: 64516 .
>>
>> Someone, the compiler manages to do a signed arithmetic shift
>> on an unsigned.
>
> [The spec
> says](https://dlang.org/spec/expression.html#shift_expressions)
> that `>>` means *signed* shift right. `>>>` is for unsigned
> shifts. So pedantically speaking, 64516 is the correct result.
>
> It's another issue whether that's good design though. For one,
> it breaks the rule "do what C does, or don't compile". It'd be
> more reasonable if `>>` was type-dependant shift right (as in
> C) IMO.
Not really. If you just do `>>` (i.e. not `>>=`), then you get
1028.
```d
import core.stdc.stdio: printf;
void main() {
ushort ee = 32896; //starting from the second shift
ushort ee_result = ee >> 5u;
printf("the value of ee_result is %d\n", ee_result); //the
value of ee_result is 1028
}
```
The problem is the combination with assignment, which is what
makes it seem like a bug. According to [1], "the right operand is
implicitly converted to the type of the left operand, and
assigned to it." So what should happen is that `5U` is implicitly
converted to `5` and a signed conversion should happen. The
result should be 1028. 64516 seems like a weird result.
[1]
https://dlang.org/spec/expression.html#simple_assignment_expressions
More information about the Digitalmars-d
mailing list