ZDoom

[url=https://github.com/coelckers/gzdoom/commit/66d9ec00a7e438c309ec49e241a90236243554b8]Added workaround for x64 codegen in MSVC 2015.[/url]

In that case I vote for disabling optimization for VS2015. That can later easily be removed when we really want to move on to a more modern C++ standard.

In order to fix Windows x64 devbuilds we can disable optimization around [url=https://github.com/coelckers/gzdoom/blob/fc5420bf266596d59f027a98773bb95915b9f144/src/g_game.cpp#L223-L243]turbo[/url] CVAR or rewrite [url=https://github.com/coelckers/gzdoom/blob/fc5420bf266596d59f027a98773bb95915b9f144/src/g_game.cpp#L238-L241]this part[/url] using an intermediate volatile variable. Both solutions work for me.

That post was rather pointless. We have already confirmed that this is a compiler bug in Visual C++ 2015, but do not know a workaround yet how to escape it.

Crashes for me too.

Inside a level the listener cannot be null because the camera cannot be null, so if it is null, the sound cannot really be a level sound. Yes, you are correct about that assumption, such a sound should not really play when there is no listener.

I wanted to submit the same change, but it was not enough. Listener can be null [url=https://github.com/coelckers/gzdoom/blob/457969262d077f86cca5050788cf46e0c6247b1f/src/s_sound.cpp#L694]here[/url] as well.
This one is a bit tricky. Am I right that if [b]type[/b] is not [b]SOURCE_None[/b], listener and level should not be null?

[quote="_mental_"]Are you sure it's the same crash? At the moment it crashes for me in [url=https://github.com/coelckers/gzdoom/blob/73fd072d10a5141356e7eb8bdc9011b63ac6a2e5/src/s_sound.cpp#L2190]S_UpdateSounds()[/url] with [b]listenactor[/b] being null.
This is completely unrelated to a potential code generation bug in VS2015.[/quote]


I pushed a quick fix for this. Since the global timer needs to be moved out of the level struct anyway I'm not bothering with a complete fix for now.

Oh, I'm unsure about that. In that case I'll make a separate bug report with a crash log, to rule out bad compiler crash.

Are you sure it's the same crash? At the moment it crashes for me in [url=https://github.com/coelckers/gzdoom/blob/73fd072d10a5141356e7eb8bdc9011b63ac6a2e5/src/s_sound.cpp#L2190]S_UpdateSounds()[/url] with [b]listenactor[/b] being null.
This is completely unrelated to a potential code generation bug in VS2015.

I just tried to build g73fd072d1 and I'm getting crash on startup too.

VS2017 Community 15.9.3
Yes, hard-deleted and re-generated build directory with CMake

Nothing, still crashes.

[quote="Graf Zahl"]Or we may simply unsupport VC++ 2015 for being buggy.[/quote]
This is more or less fine except right now the build machine is stuck with 2015. Hoping to resolve before the end of this month. So far Microsoft partners (since Microsoft's site points to contacting partners for it) are just ignoring my inquiries for volume licensing, so going to try just calling Microsoft soon.

Confirmed, I upgraded to VS2017 and ran CMake targeted for VS2017. It all works now.

Yeah, this is definitely a compiler bug. AppVeyor's VS2015 builds crash too, while the VS2017 builds don't.

	0f 5a d1	 cvtps2pd xmm2, xmm1
  00055	f2 0f 59 15 00
	00 00 00	 mulsd	 xmm2, QWORD PTR __real@3f847ae147ae147b

Definitely a code generation error.

Here's the assembly output of the first bad section:

[code]
0f 5a d1 cvtps2pd xmm2, xmm1
00055 f2 0f 59 15 00
00 00 00 mulsd xmm2, QWORD PTR __real@3f847ae147ae147b
[/code]

You can see the first instruction being fully there, but the second one is garbled (but still locatable), there's 3 bytes of garbage in between. To be honest, I don't know how to handle it, someone with a broken compiler needs to do this.
Or we may simply unsupport VC++ 2015 for being buggy.