Architectures where unaligned access is (not) OK?

[Simon McVittie <smcv@debian.org>]

A couple of questions for people who know low-level things:

* Of Debian's architectures (official and otherwise), which ones are
  known/defined/designed to be OK with unaligned accesses from
  user-space, and which ones (can be configured to) crash or give wrong
  answers?

* Would it be safer to assume that future architectures are in the
  "unaligned accesses are OK" category, or the "not OK"
  category?

The ones I know for sure are:

- OK: any-i386, any-amd64
- not OK: armel

I believe powerpc, s390 and arm64 might be in the "OK" category, and
mips* and sparc in the "not OK" category. I've seen conflicting
information about which category armhf is in: on #757037, Marc
Kleine-Budde said that ARMv6 and up guarantee that unaligned access is
fine, but I've also found Ubuntu bug reports about unaligned access
failures on armhf.

The context is that
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757037 describes lzo2
failing to start up on armel due to unaligned memory accesses. lzo2 has
a cpp macro, LZO_CFG_NO_UNALIGNED which can be defined to stop it doing
"clever" things with casting pointers. If the maintainer doesn't object
(or fix the bug of course), I intend to NMU lzo2 to use that macro on at
least armel; I would like to sanity-check whether I should be using a
blacklist or whitelist approach, and which architectures other than
armel should be on the blacklist, or which architectures other than x86
should be on the whitelist.

Relatedly, if we have

    typedef struct lzo_memops_TU2_struct {
      unsigned char a[2];
    } lzo_memops_TU2;

    *(lzo_memops_TU2 *) (void *) dest =
        *(const lzo_memops_TU2 *) (void *) src;

is gcc within its rights to optimize that into an aligned 16-bit load
and an aligned 16-bit store, even though alignof(lzo_memops_TU2) == 1;
or should gcc be emitting pessimistic byte-by-byte code for that?

(Unfortunately this is itself a slight simplification, because this part
of lzo2 is a maze of twisty typedefs all different.)

Thanks,
    S