[Bug libc/21182] __memchr_sse2: regression in glibc-2.25 on i686

["fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21182

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
            Summary|segfaults with glibc-2.25   |__memchr_sse2: regression
                   |on i686                     |in glibc-2.25 on i686

--- Comment #7 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Leah Neukirchen from comment #6)
> I realized the machines where it works all use __memchr_sse2_bsf, but
> I couldn't yet figure out how to force them to use __memchr_sse2 instead,
> to make such a comparison trace.
> Is there a trick to override the ifunc selection?

Good observation.

Currently, recompiling glibc is the only reliable option I know of.  I used
this patch:

diff --git a/sysdeps/i386/i686/multiarch/memchr.S
b/sysdeps/i386/i686/multiarch/memchr.S
index bd0dace..4791d10 100644
--- a/sysdeps/i386/i686/multiarch/memchr.S
+++ b/sysdeps/i386/i686/multiarch/memchr.S
@@ -37,7 +37,7 @@ ENTRY(__memchr)
 2:     LOAD_FUNC_GOT_EAX (__memchr_ia32)
        ret

-3:     LOAD_FUNC_GOT_EAX (__memchr_sse2_bsf)
+3:     LOAD_FUNC_GOT_EAX (__memchr_sse2)
        ret
 END(__memchr)

With this patch, I get this output from your test case:

0 (nil)
1 (nil)
2 (nil)
3 (nil)
15 (nil)
16 (nil)
17 (nil)
4080 (nil)
4081 0xf7e4128a
4082 0xf7e4128a
4083 0xf7e4128a
4084 0xf7e4128a
4094 0xf7e4128a

So it doesn't look like an Atom-specific CPU bug, but a generic issue in the
__memchr_sse2 function.

-- 
You are receiving this mail because:
You are on the CC list for the bug.