This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: memcmp-sse4.S EqualHappy bug


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]