Dynamic recompiler bugs

[Battler]

This GRUB boot disk (http://citadel.ringoflightning.net/boot.dsk) causes PCem to fatal with: Deleting deleted block .

Saving the settings and exiting CMOS setup with the Advanced/EV causes PCem to fatal with: block->next_2->pc=0 08C29688 .

[Battler]

Saving the settings and exiting CMOS setup with the Advanced/EV causes PCem to fatal with: block->next_2->pc=0 08C29688 .

That is fixed now, but now a similar fatal occurs some time after reset: block->next_2->pc=0 073B4CF0 .

[SarahWalker]

That second bug was fixed in rev 277. There is still a bug where the memory test on both the Intel boards sometimes lasts forever after a soft reset, but I don't really know what's going on there - the loop in question doesn't appear to be capable of terminating.

[Battler]

Ever since revision 278, the emulator now crashes when hard resetting at any point except for in POST phase, at least with the 430VX.

Edit: Turns out it was not that 278 that introduced it but leilei's Voodoo patch as it crashes during Voodoo initialization on reset (I had to make it log every step it does at reset).

Edit #2: Yep, confirmed, disabling the Voodoo makes it no longer crash on reset.

[leilei]

Doesn't happen for me. Then again you did fail to mention your compiling switches which were most likely this

Code: Select all

basecflags = -O3 -march=core2 -fomit-frame-pointer -ffast-math -msse -msse2 -msse3 -mssse3 -mfpmath=sse -DDYNAREC

as mine were

Code: Select all

CFLAGS = -O3 -march=i686 -fomit-frame-pointer -DDYNAREC

[Battler]

Well there's still a bug in the code if using better optimization switches causes emulator crashes. :p

[SarahWalker]

Yes, but it then becomes a bug that's impossible to reproduce and fix if they aren't supplied...

[Battler]

Well, a friend of mine did some testing just now and it seems that the crash is because of architecture set to core2 instead of i686.

Edit: I just did a test myself... the crash occurs inside voodoo_generate_filter, and for some reason, having it log every single step of both loops make it no longer crash. It seems as if something goes wrong when the loop executes too fast.

[SarahWalker]

Sounds like it might be a compiler bug. You could compare GCC's output between i686 and core2, but to be honest there's probably not much point. I don't think there's any significant advantage in going beyond i686 anyway.

[Battler]

- Tom Walker: No, my friend tried setting it to i686 too, it still crashed. It might be a result of too fast hardware (though then I wonder why it would happen on my Pentium Dual-Core E5700).

[SarahWalker]

Have you tried running GDB on it?

[nerd73]

It does not happen for me (on an Athlon II X2 255 3.1 GHz) on March-i686 with -DDYNAREC enabled.