#define 'HAVE_UNALIGNED_ACCESS' and [-Wcast-align] warnings on 32bit armv7l about ccan HOT 3 OPEN

Additional Info:
lightning/external/libwally-core/src/ccan_config.h
has also same logic.

 31 #if HAVE_UNALIGNED_ACCESS
 32 #define alignment_ok(p, n) 1
 33 #else
 34 #define alignment_ok(p, n) ((size_t)(p) % (n) == 0)
 35 #endif

Sould be the following?

 31 #if HAVE_UNALIGNED_ACCESS
 32 #define alignment_ok(p, n) ((size_t)(p) % (n) == 0)
 33 #else
 34 #define alignment_ok(p, n) 1
 35 #endif

from ccan.

from ccan.

Thank you very much for your comment.
Sorry for late response.

Please forgive me what I can is leave some unorganized comments for now because this problem includes some composite and difficult issues.

HAVE_UNALIGNED_ACCESS=0 --> pointers are aligned appropriately in advance.
HAVE_UNALIGNED_ACCESS=1 --> pointers may not be aligned. need check and re-align.

No. HAVE_UNALIGNED_ACCESS=1 means you can access pointers with "unnatural" alignment. x86, for example, allows you to do this.

1. Your answer is very useful information for me. Thanks again. Where is the detailed document about that kind of #define directives meaning and explanation?
2. As you said, I know almost all x86 instructions allow “unnatural” alignment access except SIMD instructions. Some SIMD instructions, for instance, movdqa cannot unaligned access, if do it, raise exception. On the other hand, movdqu can unaligned access. But it may slow down because it reads memory twice over the each aligned boundary.
3. In my opinion, just intuition, the existence of HAVE_UNALIGNED_ACCESS is “unnatural” coding because it expects and relies on a processor exact behavior too much.
4. I wonder why you allow “unnatural” alignment access even though your code is optimized very well. “unnatural” alignment access might slow down your code.
5. I know some x86 series itself is optimized enough fast for unnatural alignment access. But too many series to support by software.
6. I found ARM document about memory alignment and instructions. I hope it’s useful for you unless you have read it already.
   How does the ARM Compiler support unaligned accesses?
7. What is the oldest compiler to support CCAN repository? I’d like to insert actively some kind of __atribute__ ((aligned(x)) directives to the important pointers. Of caurse, CCAN can wrap that dicrectives by macro for compatibility.

Interestingly, my rPi thinks it can do it too, but perhaps unaligned
accesses actually trap, and it would perform better with this unset?

This is also my guess, it relates virtual memory allocates granularity, or, ARM processor’s failure. If the former, x86s allocates at least 4KB and didn’t touch non-commitment area by lucky. Anyway, As I told you at (3), to believe processor manufacturer’s document completely is sometimes risky in my opinion. I know Prof. Tanenbaum and David N. Cutler were consumed time by that kind of issues.

Current conclusion:

If I were you, when ARM processor detect by configure or make, I allocates alignment sensitive memory area by only aligned memory allocate functions. And, add __attribute__ ((aligned(x)) attributes to the all sensitive pointers. If target processor is x86(AMD), I don't change the result of processed code at all. I'll remove HAVE_UNALIGNED_ACCESS macro (at least, statically).
I'm not sure for the other processors. (What's supported?)

Best Regards,

from ccan.