fusion: Don't assume a specific compiler behaviour

[André Hentschel]

Am 19.07.2012 22:06, schrieb Ruslan Kabatsayev:
> Hello,
> 
>> Most likely it's rotated on x86 and hardly shifted on ARM, damn compilers.
> No, it's not compilers, it's intel's "shr" instruction behavior: it
> masks bit count lower 5 bits, thus making 33 effectively 1.
> Corresponding ARM instruction most likely does true 33 bit shift
> giving you zero result.
> 
> Regards,
> Ruslan
> 
> PS I didn't look at types your patch works on, but be careful to not
> mess up 64 bit types this way.
> 
> On Thu, Jul 19, 2012 at 11:49 PM, André Hentschel <nerv at dawncrow.de> wrote:
>> maybe it's some braindamage by me, but when i is greater or equal to 32 a shift of HighPart by e.g. 33 doesn't make much sense. For some reason this works on x86 but not on ARM. Most likely it's rotated on x86 and hardly shifted on ARM, damn compilers.
>> If i'm right i don't want to know how much places there are in Wine with assumptions like this, i'll most likely find them with the testsuite on ARM, but i's quite hard to get to the point where you see them...

Hi Ruslan,
Thanks for your explanation. The type of HighPart is LONG, i guess that's fine, 64-bit won't make sense here.


-- 

Best Regards, André Hentschel