<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:hhinnant@apple.com" title="Howard Hinnant <hhinnant@apple.com>"> <span class="fn">Howard Hinnant</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - compare function with equal semantics cause std::sort function core dump"
href="http://llvm.org/bugs/show_bug.cgi?id=16819">bug 16819</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>INVALID
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - compare function with equal semantics cause std::sort function core dump"
href="http://llvm.org/bugs/show_bug.cgi?id=16819#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - compare function with equal semantics cause std::sort function core dump"
href="http://llvm.org/bugs/show_bug.cgi?id=16819">bug 16819</a>
from <span class="vcard"><a class="email" href="mailto:hhinnant@apple.com" title="Howard Hinnant <hhinnant@apple.com>"> <span class="fn">Howard Hinnant</span></a>
</span></b>
<pre>There's two questions here:
1. Why does >= cause sort to crash.
Section 25.4 [alg.sorting]/p3-p4 says:
... comp has to induce a strict weak ordering on the values.
The term strict refers to the requirement of an irreflexive relation (!comp(x,
x) for all x) ...
When comp is >=, it violates the "strict" requirement, for example 3 >= 3 is
true instead of the required false.
2. Why does sort sometimes compare an element to itself?
This is done within two tight loops within this implementation of std::sort,
here is one of them:
// __m still guards upward moving __i
while (__comp(*__i, *__m))
++__i;
Instead of doing this:
// __m still guards upward moving __i
while (__i != __m && __comp(*__i, *__m))
++__i;
In general the extra self-compare done once in this loop will be far cheaper
than the iterator compare on each iteration of the loop. The algorithm goes to
extra trouble just to set up this "unguarded loop" just because the
optimization is so compelling.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>