This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: memcmp-sse4.S EqualHappy bug
- From: "Dr. David Alan Gilbert" <dgilbert at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Andrea Arcangeli <aarcange at redhat dot com>, 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 19:12:19 +0100
- Subject: Re: memcmp-sse4.S EqualHappy bug
- Authentication-results: sourceware.org; auth=none
- References: <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> <20150618161943 dot GN14955 at redhat dot com> <20150618172231 dot GS14955 at redhat dot com> <1434649785 dot 30819 dot 37 dot camel at localhost dot localdomain>
* Torvald Riegel (triegel@redhat.com) wrote:
> On Thu, 2015-06-18 at 19:22 +0200, Andrea Arcangeli wrote:
> > On Thu, Jun 18, 2015 at 06:19:43PM +0200, Andrea Arcangeli wrote:
> > > workload. That it can only return non zero is defined by the hardware
> > > and trivial to enforce in the workload of my testcase.
> >
> > Instead of thinking in hardware terms, our colleague David (CC'ed)
> > suggested we can explain why there is a problem in C terms as well.
> >
> > While the compiler would be free to reorder the load/stores if you
> > wrote the memcmp in C, and it would be free to duplicate a read, it
> > would never be free to terminate the comparison loop due any equal
> > result.
>
> If there are data races, this is undefined behavior and *all* bets are
> off (according to the standard). This includes results such as
> terminating the loop, stopping to do anything, etc.
>
> This may seem overly drastic, but it's a useful line to draw because we
> don't want to have to reason based on details of a compiler's
> implementation.
Yes, I guess what I find interesting about this case is that:
a) Having found a difference and then reread it and found it identical
you *know* you've hit an 'undefined' case.
b) The action taken in that case is an outcome that seems impossible
from any memory reordering or pure-rereading of data; so it's more
surprising than normal - people are already used to the compiler
or the CPU reordering stuff, and having static mismatched data
in the block would seem to be a guarantee that 0 could never
happen.
c) I worry if there's anything where a strcmp could get optimised
into a memcmp and then hit this case, but I agree it's difficult to
find a situation where it would have been safe anyway.
IMHO it would be safer to abort than to return 0, but that's probably
an equally controvercial result.
Dave
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK