riscv: configure.ac bug fix for misaligned access when __riscv_misaligned_slow

[Pincheng Wang]

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