Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses]

[Ian Lepore]

On Fri, 2016-05-27 at 09:30 +0200, Matthias Andree wrote:
> Am 27.05.2016 um 06:14 schrieb Cedric Blancher:
> > 
[...]
> 
> 
> 2 - find someone to review the ARM and AARCH related #if preprocessor
> stuff in ./include/lzo/lzodefs.h in the port's WRKSRC after
> unpacking.
> 

I just had a look.  I think the cause of bugzilla 207096 is probably
found on line 2544 of lzodefs.h:

#  elif 1 && defined(__TARGET_ARCH_ARM) && ((__TARGET_ARCH_ARM)+0 >= 7)

A similar check on line 2551 assumes armv6-a and -r profiles also
support unaligned.

Our freebsd clang would normally not define __ARM_FEATURE_UNALIGNED
(checked on line 2528 of lzodefs.h) unless someone had specifically
added the -munaligned-access option; in the PR we see it specifically
has -mno-unaligned-access.  But it also has -march=armv7 (our default
is v6 due to the rpi and the ongoing stupidity that we pretend v6 and
v7 are "the same enough" to not need separate names).

So with __ARM_FEATURE_UNALIGNED not defined and arch = armv7, the check
on line 2544 makes the assumption (incorrect until a few days ago) that
if the arch is v7, we must have support for unaligned access.  I think
that assumption is right for every major OS, but there could be special
embedded environments where it's incorrect.  (In fact, a highly
specialized embedded system is pretty much the ONLY place you'd expect
someone to legitimately disable unaligned accesses, now that freebsd
gets it right).

I think the right thing to do is: if __ARM_ARCH is defined, that means
the current compiler properly supports the ACLE feature symbols[1] and
thus only __ARM_FEATURE_UNALIGNED should be consulted.  If __ARM_ARCH
is not defined, then __ARM_FEATURE_UNALIGNED can't be used, and a
fallback to guessing based on arch might be valid.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf

-- Ian