[PATCH 07/11] Fix strcmp bug for little endian target
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Thu Jan 23 18:23:29 GMT 2025
On 23/01/25 10:43, Aleksandar Rakic wrote:
> Strcmp gives incorrect result for little endian targets under
> the following conditions:
> 1. Length of 1st string is 1 less than a multiple of 4 (i.e len%4=3)
> 2. First string is a prefix of the second string
> 3. The first differing character in the second string is extended
> ASCII (that is > 127)
>
> Cherry-picked 7c709e878f836069bbdbf42979937794623cfa68
> from https://github.com/MIPS/glibc
>
> Signed-off-by: Faraz Shahbazker <fshahbazker@wavecomp.com>
> Signed-off-by: Aleksandar Rakic <aleksandar.rakic@htecgroup.com>
> ---
> sysdeps/mips/strcmp.S | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/sysdeps/mips/strcmp.S b/sysdeps/mips/strcmp.S
> index 4878cd3aac..8d1bab12ec 100644
> --- a/sysdeps/mips/strcmp.S
> +++ b/sysdeps/mips/strcmp.S
> @@ -225,10 +225,13 @@ L(worddiff):
> beq a0, zero, L(wexit01)
> bne a0, a1, L(wexit01)
>
> - /* The other bytes are identical, so just subract the 2 words
> - and return the difference. */
> +# if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> + srl a0, a2, 24
> + srl a1, a3, 24
> +# else /* __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ */
> move a0, a2
> move a1, a3
> +# endif /* __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ */
>
> L(wexit01):
> subu v0, a0, a1
Can't you use the generic implementation instead? If I understand correctly,
mips optimizes only the aligned case, while generic code also do word size
read for unaligned case (with the MERGE and shift tricks). The only trick
I see that mips implementation does is loop unrolling, which I think you
can do by adding some compiler flags on mips Makefile.
More information about the Libc-alpha
mailing list