Counter Strike Global Offensive doesn't start with mesa compiled with -march=native

[ChristophHaag]

As I said in irc, this log is from mesa git with nine/master merged in, compiled with --enable-debug with these cflags: -march=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 with NINE_DEBUG=all
https://gist.github.com/anonymous/d644e92447e1fa1518a3

When mesa is compiled with CFLAGS="-O2" csgo works flawlessly. When mesa is compiled with CFLAGS="-O2 -march=native", csgo does not start.

Another application I tried is skyrim. Skyrim starts either way. With AND without -march=native.

Maybe I should also say: I use an i7 3632qm (ivy bridge).

[siro20]

I've compiled mesa with -march=native and without this compiler flag, but it doesn't make any difference. The game starts and runs fine regardless of the CFLAGS chosen.
Tested on ivy bridge and AMD HD6870.

[ChristophHaag]

Maybe it's a compiler version thing? I used gcc 5.1 on archlinux.

[siro20]

Tested again with GCC 5.1.1 and I can confirm:
I got a crash at the same function when compiled with -march=native.
Last line is:
"nine:nine_state_copy_common_all: Fixed function state not handled properly by StateBlocks."
I do not see a crash when compiled without -march=native.

[siro20]

crashes here:
memcpy(dst->ff.active_light, src->ff.active_light, sizeof(src->ff.active_light) );
maybe it's a compiler bug ?

[iiv3]

@siro20 , most likely a compiler bug.
Try to get the assembler code that is produced for this instruction, with and without native.
See what is the value of the passed pointers.

I do suspect that SSE instructions are used for memory transfer but some of the pointers is not aligned. Adding -fno-tree-vectorize or mno-sse to CFLAGS might workaround it too.

Making the smallest program that replicates it might be the most tricky part.

[siro20]

replacing the memcpy with a loop resolves the problem.
-march=native -mno-sse resolves this problem, too.

Both addresses are 8 byte aligned.
I couldn't find any documentation what sse enabled memcpy is doing.
Maybe it doesn't check for alignment ? Why doesn't it crash in other locations ?

[siro20]

This is a compiler/libc bug.
It crashes as the memcpy is exactly 16byte. 16bytes can be copied with a single instruction.
I increased the array size to 32 and the bug is gone. cs:go is working again.

[iiv3]

@siro20, could you check the alignment of dst, src pointers and the offset of the field in the structure?
Also, what allocates these structures?

I do not think it is glibc bug, since gcc tries to inline fixed sized memcpy operations.

[siro20]

It's allocated by creating device9.
Both addresses are 8 byte aligned.
SSE is able to handle unaligned memcpy, so this should not be an issue. It crashes on every 16byte memcpy, not only in stateblock9.c, while memcpy of other sizes are OK.
I wasn't able to write a test program that shows the crash, does mesa add additional CFLAGS?

[iiv3]

Yes, SSE is able to handle unaligned access, by using two instruction for the load, instead of one.
The question is more, why gcc thinks that the pointers are SSE-aligned when there is no really such requirement (e.g. malloc is 8 byte aligned).

The CFLAGS should be in the Makefile.

[ChristophHaag]

I'm pretty sure that was also fixed with 29e2ccf. At least I think I have it with march=native again and it doesn't crash.

Someone please reopen if not.