Created attachment 357160 [details, diff] the patch that works around the problem I'm unsure if this is a gcc bug and if it should be filed here, but I'm kinda out of options. http://sourceforge.net/projects/vavoom/ Both the latest (1.33) and from svn when built with >= '-O' result with an unworking executable when built with 4.8.1. It works fine up to 4.7 series. At a point, I though it might be a matter of a single file, I've even filed a bug in gcc bugzilla with a preprocessed file (source/snd_flac.cpp) that seemed to make things work by being built without '-O', but the bug was sort of rejected for missing a real testcase and my further tests gave an odd result. vavoom seems to be a bit quirky in the methods it uses for exception handling and memory allocation. To offset this (well, only in regard to memory allocation), in libs/core/zone.h, there's ZONE_DEBUG define. When I built vavoom with it set, it worked on 4.8 even with '-O2'. In fact, even with it unset, only using some of the changes triggered by ZONE_DEBUG (see attached patch) was sufficient to make it work. I can't tell whether the fault lies on vavoom or gcc side, but it might be something you should be aware of.
Just a few details I've skipped. 1. Problem happened on an amd64 machine, but I don't think it's arch specific. 2. "the broken executable" refers to vavoom.bin, not wx frontend (which I'm not building anyway) 3 vavoom is built WITH_FLAC, WITH_LIBMAD,WITH_OPENAL, WITH_OPENGL, WITH_SDL, WITH_VORBIS, but not WITH_MIKMOD
What's the upstream PR number? Exactly what failure are you getting (what does "unworking" mean? crash? incorrect output)? What are the steps to reproduce it?
Well, it's PR58174, but to be honest, they were kind of right rejecting it. The failure is a segfault upon './vavoom -openal -opengl -<game name>' during startup shortly after it switches resolution.
