Bug 482656 (PR58174)

Summary:	sys-devel/gcc-4.8.1 might miscompile at >= -O
Product:	Gentoo Linux	Reporter:	Rafał Mużyło <galtgendo>
Component:	[OLD] GCC Porting	Assignee:	Gentoo Toolchain Maintainers <toolchain>
Status:	RESOLVED NEEDINFO
Severity:	normal
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
URL:	https://gcc.gnu.org/PR58174
See Also:	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58174
Whiteboard:
Package list:		Runtime testing required:	---
Attachments:	the patch that works around the problem

Description Rafał Mużyło 2013-08-27 10:24:42 UTC

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.

Comment 1 Rafał Mużyło 2013-08-27 12:43:29 UTC

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

Comment 2 Ryan Hill (RETIRED) gentoo-dev

2013-08-28 05:27:08 UTC

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?

Comment 3 Rafał Mużyło 2013-08-28 11:50:43 UTC

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.