Fix duplicates using custom compare with bitonic block sort

[rosenrodt]

I have modified test case to reproduce the issue as described in #774. And a fix is proposed

Tested on:

• Nvidia Geforce GTX1060
• AMD Radeon HD 6770

[jszuppe]

Thanks! I'll look into today or later this week and merge.

[jszuppe]

It would be great if you can change the order of commits: first test which shows the bug, then commit with a fix. Please reference issue id in the fix commit. If you have problems with doing that, or don't know how to do it using git, don't worry, I'll do that for you. Thanks again for submitting a fix and testing it on two platforms!

[rosenrodt]

I’ll do that once I get back to my computer. Do I simply force-push to rewrite the git history?

[jszuppe]

Yes, force push will work.

[rosenrodt]

@jszuppe thanks. i've rearranged the commits

[jszuppe]

After looking at it.

1. Will it work correctly if we do opposite: force them not to do the swap if they are equal? This is always one local memory operation less. I think the bug is/was that if there are equal values one is swapped and one is not.
2. If 1. does not work, then I think we can at least limit your fix to sort_by_key situation only.

But in generally fix is ok.

[rosenrodt]

1. That will do too. I have pushed them too in the PR
2. The fix concerns bitonic_block_sort with sort_by_key = false. So I am not sure what you mean by that. Although I haven't looked into it but does the CPU equivalent or bitonic_block_sort with sort_by_key = true could possibly repro issue Wrong sort results using customized compare #774 too?

btw the Travis build server seems to complain about missing CL.h

[jszuppe]

1. Ok
2. Yeah, you're right. I think it can apply sort-by-key situation too with keys, but of course this fixes also that problem.

[jszuppe]

btw the Travis build server seems to complain about missing CL.h

Yeah, I'll have to fix Travis CI script someday.... Too much work at work ;)