|
|
>> OK, but the following code from lccwin does not appear to set up the shift
>> count in cl register. So you don't even attempt to shift by 32, but by an
>> unknown value in cl (presumably 24)?
>>
>> ; 6 printf("%d\n",(int)1 << (int)32);
>> .line 6
>> movl $1,%edi
>> movl $32,%esi
>> sall %cl,%edi
>>
>> On the x86 at least, shifting a 32-bit register left by 32 is anyway a
>> no-operation (the register is unchanged).
>>
>> So the OP should not rely on 32+ bit left-shifts working as he expects.
>>
>
>Surely not. Things go as follows:
>
>lcc-win discovers that we have a shift operation with
>two immediate constants. This should be done at
>compile time to make the generated program more efficient.
>
>Then it discovers that one of the constants is too big
>and generates a warning. Apparently, when making this
>optimizations it doesn't set cl.
This is not a bug. 1 << 32 invokes the wrath of undefined behavior.
Since no possible answers are wrong, you might as well get one
quickly, even if it's random crap.
>If you change the program to
> 5 printf("%d\n",(int)1 << (int)31);
> .line 5
> pushl $-2147483648 // Shift done at compile time
> pushl $_$2
> call _printf
> addl $8,%esp
>
>You see?
>
>Now, it can be argued that this is a bug. True.
I'll argue that the wording of the error message is a
quality-of-implementation issue.
>I have changed this now so that it will do the shift at compile time,
>returning whatever the result is at compile time (1) anyway.
|
|