Re: [hatari-devel] Overflow warnings (was: MEMWATCH freezes Hatari)

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 10/11/18 4:40 PM, Nicolas Pomarède wrote:
> Le 11/10/2018 à 15:25, Uwe Seimet a écrit :
> > Hi,
> >
> > First of all, I sometimes get messages like this:
> >
> > /home/us/hatari/hatari/src/cpu/cpuemu_0.c:15856:53: runtime error: 
> > left shift of 65535 by 16 places cannot be represented in type 'int'
> > /home/us/hatari/hatari/src/cpu/newcpu_common.c:402:7: runtime error: 
> > left shift of negative value -60
> > /home/us/hatari/hatari/src/cpu/cpuemu_0.c:32322:22: runtime error: 
> > signed integer overflow: 1658716160 + 1658716160 cannot be represented 
> > in type 'int'
> > /home/us/hatari/hatari/src/cpu/cpuemu_0.c:26895:22: runtime error: 
> > signed integer overflow: 1911522030 - -913332782 cannot be represented 
> > in type 'int'
> > /home/us/hatari/hatari/src/cycles.c:80:21: runtime error: signed 
> > integer overflow: 2147483180 + 752 cannot be represented in type 'int'
>
> It's harmless, mostly mixing some signed/unsigned values, but the result 
> is correct.

That's not a safe assumption at higher optimization levels in modern
GCC & LLVM compilers.

Signed integer overflow and oversized shift amounts are undefined
behavior in C, and therefore it's valid compiler behavior if
the generated code e.g. formats your hard drive.

See: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Such code would need to be fixed.


	- Eero

> > When starting ROMSPEED I get this before the double bus fault:
> >
> > /home/us/hatari/hatari/src/cpu/newcpu.c:3460:14: runtime error: left 
> > shift of 1 by 31 places cannot be represented in type 'int'
>
> not a problem, code is "ps |= 1<<31", it will work. This could be fixed 
> by writing "ps |= 1UL<<31"
>
> > With MEMWATCH there is no change, the screen is cleared when starting
> > any program after it, and then the systems hangs.
> >
> > With FIX24 I get:
> >
> > /home/us/hatari/hatari/src/cpu/maccess.h:59:16: runtime error: store 
> > to misaligned address 0x5563b5929f8a for type 'uae_u32', which 
> > requires 4 byte alignment
> > 0x5563b5929f8a: note: pointer points here
> >   13 2e  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 
> > 00 00 00 00  00 00 00 00 00 00
> >                ^
> > /home/us/hatari/hatari/src/cpu/maccess.h:43:9: runtime error: load of 
> > misaligned address 0x5563b5929f8a for type 'uae_u32', which requires 4 
> > byte alignment
> > 0x5563b5929f8a: note: pointer points here
> >   13 2e  00 00 12 98 34 76 00 00  00 00 00 00 00 00 00 00  00 00 00 00 
> > 00 00 00 00  00 00 00 00 00 00
>
> This is a program running from TOS writing/reading a long at non-long 
> aligned location. It works anyway, it's just less optimal.
>
> So unfortunately, sanitize option doesn't help much.
>
> Just to be sure these are not some specific settings, could you try 
> copying romspeed on a floppy image "floppy.st", then temporarily remove 
> ~/.hatari/hatari.cfg to run hatari with its default setting, adding just 
> parameters --tos , --ttram and -s ?
> for example :
>
> ./hatari --machine tt --tos ~/Emul/ST/tos306fr.img -s 8 --ttram 16 --mmu 
> on --addr24 off --cpu-exact off --compatible off floppy.st
>
> then run romspeed from the desktop.
>
> If it bombs, I'm running out of idea :(
>
> Nicolas