fix alignment on SPARC

[dimpase]

this fixes #2191

[fingolfin]

We already perform an alignment check for long (which I reckon is only a 32bit int on most supported systems(, which sets C_STACK_ALIGN to the required alignment. That in turn is used in gasman.

That said, both the AX_CHECK_ALIGNED_ACCESS_REQUIRED macro added here, and also the existing GP_C_LONG_ALIGN M4 macro which sets C_STACK_ALIGN, strike me as incorrect for this PR: You need to know the required alignment for an uint64_t, but the former macro checks that for an int, and the latter for a long (actually, the latter hard codes a result for some platforms and falls back to a test for others, e.g. ARM).

Arguably GP_C_LONG_ALIGN is also incorrect for what we use it in GASMAN, as we need it for pointers there resp. UInt (which is uint64_t on a 64bit arch).

Finally, one may wonder what the actual expected alignment for the p argument to getblock8 is. Inspecting the code, I think it always points to an even address, though strictly speaking nothing in the API guarantees this. So I think if using C_STACK_ALIGN, one would have to test #if C_STACK_ALIGN != 1 and that would mean memcpy gets used even on x86 (as for some reason, we hardcode an alignment of 2 there).

In summary, I think we need to fix GP_C_LONG_ALIGN (independent of this PR). And for this PR, it might be best to always use memcpy in here... I wonder if gcc and clang might even be clever enough to optimize it away when used here. on x86...?

[dimpase]

Thanks. I've created #2196 to replace this one.