Re: [hatari-devel] undefined behaviour fixes

[Andreas Grabher <andreas_g86@xxxxxxxxxx>]

> Am 06.01.2025 um 14:26 schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
> 
> Le 06/01/2025 à 14:11, Andreas Grabher a écrit :
>>> Am 06.01.2025 um 12:47 schrieb Thomas Huth <th.huth@xxxxxxxxx>:
>>> 
>>> Am Mon, 6 Jan 2025 12:32:43 +0100
>>> schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:
>>> 
>>>>> Am 06.01.2025 um 12:10 schrieb Thomas Huth <th.huth@xxxxxxxxx>:
>>> ...
>>>>> All those other casts for left-shifting signed values look rather
>>>>> cumbersome, since all modern CPUs nowadays should just get this right
>>>>> (AFAIK). Maybe it's better to compile with "-fwrapv" and call it a day?
>>>> 
>>>> I prefer casting to the correct type because 1U might have different size on different platforms.
>>> 
>>> It should not be any problem when the size of int is > 32 bits, and with
>>> size of ints < 32 bits, the whole code won't work anyway, I guess.
>>> 
>>>> I’m not sure we can ignore the shifting and overflow issues. There is no „right“. Different platforms/CPUs might behave differently. I already run into such an issue when running Previous on ARM for the first time. There was a very hard to debug difference in handling overflow while casting from float to int.
>>> 
>>> Yes, but this is about representation of negative integer numbers, and
>>> AFAIK all modern CPUs use two's complement in that case. So you're trying
>>> to fix the code here for CPUs that are not in use anymore since > 40 years,
>>> I guess.
>>> 
>>> See also:  https://stackoverflow.com/a/3789752
>>> 
>>> I'd suggest that you try to add "-fwrapv" to the compiler flags and have a
>>> look which warnings are still left there without your patch.
>>> 
>>> Thomas
>> Using -fwrapv flag with my compiler reduces the amount of warnings. There are still some warnings about shifting beyond type size (uae_u32 x >> 32 and uae_u32 x << 32) and shifting with negative value (x << -1). Appended patch should fix them.
> 
> With which CPU models are you doing your tests and seeing runtime errors ? 68030 only or did you try other cpu ? do some errors "disappear" depending on whether MMU emulation is ON or OFF ? Or cycle accuracy is enabled ?
> 
> (just to see if these errors you get share a common code path or if they only appear on a specific cpu combination)
> 
> Nicolas
> 

Previous only works with 68030 and 68040 and only with MMU ON and cycle accuracy off (cpuemu_31 and cpuemu_32).