ZDoom

I can confirm that it works fine on Arch too now, also with GCC 6.3.1

Release configuration at [url=https://github.com/coelckers/gzdoom/commit/78b724e2809bd11fd32f6bb9f5dcb9d0c9774129]78b724e[/url] built with GCC 6.3.1 works fine on Ubuntu 16.04.
I assume that the issue was fixed by [b]dpJudas[/b]' commit.

I'd like to do some speed tests with Clang before we make the official switch since Clang does not seem to have -O3 issues - I'd probably suggest only doing it for GCC.

Another option may be to replace -O3 with -O2. I often hear "-O3 could do bad stuff in the past because of bugs, but it's fine now!" while also continuing to hear stories like this. It's also been said that -O3 may not produce more efficient code than -O2 anyway, due to over-optimizing and not accounting for things like code size effecting cache locality (and similar stories of -Os sometimes being faster than -O2/3).

I commited a version of OpenGLSWFrameBuffer::OpenGLPal::Update that does some SSE using intrinsics to prevent GCC from optimizing it using the auto-vectorizer. Hopefully that should make it stop crashing at this location.

If this one function is the only crash we have, then I can fix it by rewriting it. Its current version looks visually terrible anyway.

Well, SSE support isn't completely broken with GCC, it simply has some issues.
Most of Linux distros use GCC by default and disabling SSE would be an overkill.

Moreover I doubt that it's possible to disable SSE for x64 builds.
At least floats/double are passed to functions using XMM registers.

Actually, this can be the only problem we have with this instruction set in GCC.
Need to think what will do with it though.

[quote="Rachael"]Can that be done on specific files like r_all.cpp and poly_all.cpp rather than the entire project?[/quote]


Those two files contain all relevant SSE code, so it'd be a bad idea.

Ah. >_> My mistake.

As far as I know, the broken code isn't part of those files. But I was more thinking of specifying something like -fno-tree-vectorize globally, or whatever other pass it is that causes it to crash.

Can that be done on specific files like r_all.cpp and poly_all.cpp rather than the entire project?

It would probably be better to specify the flags disabling the optimization passes that is causing the problem rather than try disable SSE completely. The software renderer runs at half its normal speed if you define NO_SSE.

Should we pass -DNO_SSE if CMake detects it is using GCC by default, for now, until GCC gets a chance to fix those issues? And then recommend officially switching to Clang if someone wants a proper executable with the intrinsics enabled?

I had several issues with GCC code generation involving SSE instructions: broken auto-vectorization, broken alignment even for l-values, invalid transformation of intrinsics to instructions, ... Their Bugzilla is full of similar "success stories".

By the way, I tested in VM without hardware acceleration, it was Mesa3D LLVMpipe driver.
AFAIK it's quite close to spec so I hope it was the same crash as in OP.

[quote="_mental_"]The result of [b]r13+r9*1+0x0[/b] (or simply [b]r13+r9[/b]) is [b]0x1848193[/b].
I believe it must be 16-bytes aligned to work.[/quote]
Hmm, yes, that instruction must use 16-byte aligned addresses to work.

Here's another guy having a similar type of crash: [url]http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html[/url]. The compiler assumes that any uint32_t is 4 byte aligned. When it generates the SSE optimized code, it makes sure it is 16-byte aligned, but [i]only[/i] if the original assumption that it was already 4 byte aligned is correct.

Could it be that one of our pointers are not properly dword aligned?

Edit: I found this information about [url=https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glMapBuffer.xhtml]glMapBuffer[/url]: "Alignment of the returned pointer is guaranteed only if the version of the GL version is 4.2 or greater." So we could very well have an alignment issue at this spot.