Uzebox Forums

I tried all optimization levels including -O0 and all failed at the same place for Alter Ego at least.

uze6666 wrote:Saw some posts on the net saying 4.8.1 may have some issue due to the optimizer. Can you try lowering or removing the -O optimization to see what happens?

I've been using the debug exe that the Makefile generates, so -O0 is enabled by default for that. I explicitly put that on the commandline and still no dice.

I back rev'ed mingw's gcc and g++ to 4.6.1 though and it's working now! WHAT THE HECK!?!

I wonder what is different and what it's doing that's causing this....

So I just tested my changes to the SPI code thus far and it looks like I didn't break the SD code for at least Alter Ego. I'm going to test the rest of them now and make sure they work too.

The other games appear to work now too. So I can continue with my work on getting SPI RAM into the emulator.

Good job figuring that problem out guys and there is at least a working solution. It's truly bizarre that the newest version of GCC chokes on that code. I think it is pretty standard for most people to do like I always do and use the latest versions of everything, when I setup something like MinGW. So I suspect there will be problems in the future and some forum work to be done to tell people about this anomaly, and time waste is never good. Maybe it's not possible, but are there any ideas how we could make this work correctly in all GCC versions? Maybe it's some new struct packing we could fix with #pragma

It might not be a struct packing issue and with some more time, I can probably figure it out. I am wondering if it's some kind of variable size thing. Actually, I might investigate that. It is possible something changed the size of what u16 translates to or something like that.

I would not waste a single second investigating this problem. GCC 4.8.1 is already an old version. There's many newer versions that may have fixed regressions introduced in 4.8.1. I'd wait for a MinGW version with those fixes.