Comment # 5 on bug 1105608 from Michal Srb

(In reply to Sergey Kondakov from comment #4)
> Created attachment 780872 [details]
> Xorg.pid-1381.gdb.log with disas

The disassembly shows the _start function, so the illegal instruction is not
visible.

> I guess, it can be closed because it does not pertain to vanilla builds��� but
> then again, it's vanilla libstdc++ that was crashing��� so whose code at fault
> here: Mesa, gcc/libstdc++ or clang/LLVM+gold ?

Well the whole std::copy/__builtin_memcpy may be inlined and then it depends on
the configuration of the place where it was inlined. A random guess: The build
log in your Mesa package shows that SWR is built for AVX and AVX2. Your CPU
supports only AVX, so it should be selected at runtime. But maybe the LTO
somehow messed the flags and propagated the AVX2-supported flag into places
where it was not supposed to be. Then the AVX2 variant of the memcpy was used
from that place. It would be issue in the Mesa's build system, but is this
configuration even supported? I don't know and this is just wild guessing.

If you want to keep experimenting with custom Mesa build, I would suggest you
to either not build SWR at all, or try to disable the AVX2 part.

If you run into some (other) issues, report it upstream, but mention that you
are using custom build and describe your custom configuration.

Anyway, the Mesa we have in openSUSE is fine, so I am closing this bug.