I think you're semantically testing the wrong thing.

It's not if unaligned accesses are supported, it's if they are
efficient enough or not.

For example, sparc64 fully handles unaligned accesses but taking the
trap to fix it up is slow.  So sparc64 "can" handle unaligned
accesses, but whether we want to set this symbol or not is another
matter.

Yeah, good point. Should I rename it to HAVE_EFFICIENT_UNALIGNED_ACCESS
or similar? Or have it defined as some sort of number so you can make
actually make tradeoffs? Like Dave Woodhouse suggested at some point to
have get_unaligned() take an argument that indicates the probability...

johannes