Quote:
Of course I test them, and they are running perfectly stable in all the programs I tested with. Beside that, I'm running tools such as Valgrind to verify for errors that could cause such issues.
One problem with recent builds is that I switched to a newer compiler (which was needed for Omnia.9sg and Omnia.9 developement), but unfortunately the compiler turns out to have several bugs. I've had multiple instances where where the compiler itself would just crash with some internal error or segmentation failt, and several others where it didn't complain but generated broken code, which ran on some CPU's but not on others. I've asked multiple people to look into some of these issues with me to verify that it wasn't a bug in my code and they too did not understand why the compiler was doing what it did - again, only for some CPU types. So certain things might run fine on all CPU's except on certain Core2Quad models, for example.
I think that I'm close to having workarounds for all the problems with the new compiler now, but if things keep being this problematic I will switch back to the old compiler. It had other bugs (which is why I actually switched to the latest version), but at least the bugs of the old version are reasonably documented - that version is 3 years old and people have posted comments about them.
But I really prefer to stick with the new compiler, instead of having to rely on several years old software. It wouldn't be the first time though that I would have to do that. Obviously things have to be perfectly stable again before I can release a new version.
Just switch back to the old compiler for now for public builds and make some private builds for testing the new one? Saves a lot of frustration if you ask me.