As far as I understand, there may be different ways to fix it. Disable SEE (locally) with a pragma, force alignment (with a pragma or an attribute or by moving from uint32 to ulonglong — MDEV-19702).

I personally would try MDEV-19702 first, as it has value on its own, so if it'll help here — so the better.
If it won't — I'd try to see what a newer compiler does, alignment or no SSE or something else. And I'd try to force the older compiler to do the same.

Serg, moving to ulonglong is not going to help here much, because alignment required for SSE instruction operands (such as pand or por that were the culprit) is not 64bit, but 128 bit.
We tried MY_ALIGNED(16), this for the array, but this did not work out either, since the array maybe inside some struct used by optimizer, allocated not on the stack. and allocators (whether malloc, or self-backed) generally do not force the 16byte alignment. aligned_malloc() and friends could help.

In the fix I use condition on _GNUC_ < 6, for the pragma, because gcc 6.3 did work ok, but gcc 5.4 did not.

as a side note, a month ago or so, there was no sign of compiler bug on the same compilers.
http://buildbot.askmonty.org/buildbot/grid?category=main&branch=bb-10.4-wlad-MDEV-19235

Something has changed since, maybe optimizer folks extended some structures, revealing the bug, or maybe something else got compiler to optimize too aggressively

wlad, according to this https://mudongliang.github.io/x86/html/file_module_x86_id_230.html documentation, 'pand' memory operand must be aligned to 16, not to 128.

vlad.lesin Yes, this is what I'm saying, counting in bits .