This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: memcmp-sse4.S EqualHappy bug
- From: Andrea Arcangeli <aarcange at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Szabolcs Nagy <nsz at port70 dot net>, libc-alpha at sourceware dot org, "H.J. Lu" <hongjiu dot lu at intel dot com>
- Date: Thu, 18 Jun 2015 18:19:43 +0200
- Subject: Re: memcmp-sse4.S EqualHappy bug
- Authentication-results: sourceware.org; auth=none
- References: <20150617172903 dot GC4317 at redhat dot com> <20150617185952 dot GE22285 at port70 dot net> <20150617210612 dot GB14955 at redhat dot com> <1434621040 dot 5250 dot 212 dot camel at localhost dot localdomain> <20150618124900 dot GD14955 at redhat dot com> <1434637415 dot 5250 dot 271 dot camel at localhost dot localdomain> <20150618145202 dot GG14955 at redhat dot com> <1434642635 dot 5250 dot 292 dot camel at localhost dot localdomain>
On Thu, Jun 18, 2015 at 05:50:35PM +0200, Torvald Riegel wrote:
> BTW, I'm wondering what your memcmp would actually do internally, and
> what it would guarantee precisely. It can't just use relaxed-MO reads /
That's very simple: it would never return 0 if it didn't finish
comparing all the data according to the length parameter.
If minimal atomic granularity of the arch is 1, and I guarantee the
last byte is never changing and always different between src and dst
region, it would never return 0. It could return any other value but
0. It's undefined if it returns above or below zero (depending on the
modifications) but in no way my memcmp could return 0 for such a
workload. That it can only return non zero is defined by the hardware
and trivial to enforce in the workload of my testcase.