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

sorry for missed this one, I think drop __riscv_misaligned_slow is
make sense to me, we should prevent misaligned access if it's already
know to be slow.

pushed with regen configure script :)

Gedare Bloom <[email protected]> =E6=96=BC 2026=E5=B9=B45=E6=9C=8812=E6=97=
=A5=E9=80=B1=E4=BA=8C =E4=B8=8A=E5=8D=881:33=E5=AF=AB=E9=81=93=EF=BC=9A
>
> On Mon, May 11, 2026 at 10:33=E2=80=AFAM Gedare Bloom <[email protected]> =
wrote:
> >
> > On Thu, May 7, 2026 at 6:06=E2=80=AFAM Pincheng Wang
> > <[email protected]> wrote:
> > >
> > > Hi Gedare,
> > >
> > > I have a question regarding this inconsistency between the
> > > compiler-defined macro and actual hardware behavior. Please do not ta=
ke
> > > 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 <me=
mcmp+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 a=
nd
> > > > 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 t=
han
> > > aligned accesses. For hardwares that not allow unaligned access at al=
l,
> > > "__riscv_misaligned_avoid" seems to be the more appropriate macro.
> > >
> > > So, I am wondering whether this is actually a compiler issue rather t=
han
> > > a C library issue?
> > >
> >
> > This is a good point. I was taking my inspiration from the
> > implementations of memcpy and memmove, which only check for
> > __riscv_misaligned_fast.
> > I'm not sure what the right answer is for the optimization.
> >
> > Regarding my problem with alignment error, you are correct that this
> > is probably better fixed by using a multilib with mstrict-align
> > defined so that I get the _avoid variant.
> >
> This seems to work for me now. However, it does raise the question of
> whether the other optimized variants should also be checking for
> __riscv_misaligned_slow.
>
> > > > Attached fix corrects this. Generated code is now:
> > > > 00000008000baf6 <memcmp>:
> > > >      8000baf6:   469d                    li      a3,7
> > > >      8000baf8:   04c6f063                bgeu    a3,a2,8000bb38 <me=
mcmp+0x42>
> > > >      8000bafc:   00a5e7b3                or      a5,a1,a0
> > > >      8000bb00:   8b9d                    andi    a5,a5,7
> > > >      8000bb02:   c395                    beqz    a5,8000bb26 <memcm=
p+0x30>
> > > >      8000bb04:   167d                    addi    a2,a2,-1
> > > >      8000bb06:   0605                    addi    a2,a2,1
> > > >      8000bb08:   962a                    add     a2,a2,a0
> > > >      8000bb0a:   a019                    j       8000bb10 <memcmp+0=
x1a>
> > > >
> > > > 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
> > >