Re: riscv: configure.ac bug fix for misaligned access when __riscv_misaligned_slow
Pincheng Wang <[email protected]> Thu, 7 May 2026 20:06:48 +0800
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
Hi Gedare, I have a question regarding this inconsistency between the compiler-defined macro and actual hardware behavior. Please do not take this message as a review comment. On 2026/5/1 13:28, Gedare Bloom wrote: > memcmp is generating data alignment errors on risc-v targets where the > hw does not allow unaligned access. This behavior was observed on > microchip polarfire with rtems. Here is the code generated: > > 000000008000bb34 <memcmp>: > 8000bb34: 469d li a3,7 > 8000bb36: 00c6fb63 bgeu a3,a2,8000bb4c <memcmp+0x18> > 8000bb3a: 6118 ld a4,0(a0) > 8000bb3c: 619c ld a5,0(a1) > > You can see that 8000bb3a will cause a fault if a0 is not aligned and > hw does not support it. > > riscv-rtems7-gcc -dM -E - < /dev/null | grep aligned > #define __riscv_misaligned_slow 1 > According to the riscv-c-api-doc[1], "__riscv_misaligned_slow" macro shuold be defined when scalar misaligned *are supported* but slower than aligned accesses. For hardwares that not allow unaligned access at all, "__riscv_misaligned_avoid" seems to be the more appropriate macro. So, I am wondering whether this is actually a compiler issue rather than a C library issue? > Attached fix corrects this. Generated code is now: > 00000008000baf6 <memcmp>: > 8000baf6: 469d li a3,7 > 8000baf8: 04c6f063 bgeu a3,a2,8000bb38 <memcmp+0x42> > 8000bafc: 00a5e7b3 or a5,a1,a0 > 8000bb00: 8b9d andi a5,a5,7 > 8000bb02: c395 beqz a5,8000bb26 <memcmp+0x30> > 8000bb04: 167d addi a2,a2,-1 > 8000bb06: 0605 addi a2,a2,1 > 8000bb08: 962a add a2,a2,a0 > 8000bb0a: a019 j 8000bb10 <memcmp+0x1a> > > Now we have the check at 8000bb02 that will handle alignment and > falls-thru to byte-by-byte copy, or jumps to aligned long copies. > > Gedare Best regards, Pincheng Wang [1] https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/src/c-api.adoc