-0/+0
I am attaching a sample program that shows the problem. In this, the input is not simply permuted but we observe instead that some of the -0.0 are changed into +0.0 (and perhaps the other way around too).
// Before sort: -1 1 -0 0 -1 1 -0 0 -1 1 -0 0 -1 1 -0 0 -1 1 -0 0 -1 1 -0 0 -1 1 -0 0 -1 1 -0 0 -1 1 -0 0 -1 1 -0 0 -1 1 -0 0 -1 1 -0 0 -1 1 // Sorted: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 0 0 -0 0 -0 0 0 0 -0 0 -0 0 -0 0 0 0 -0 0 -0 0 -0 0 0 -0 1 1 1 1 1 1 1 1 1 1 1 1 1
If you line these up, you can see they have different numbers of characters which shouldn't happen for a permutation.
I believe it comes down to the behaviour of the min/max primitives. According to https://www.felixcloutier.com/x86/minpd (not verified), when one argument is -0.0 and the other is +0.0, both min/max will return the second argument. The current code relies on the assumption that min and max each return different ones.
A possible workaround is to swap the arguments for every min() call. That should make (min(b,a),max(a,b)) be a permutation of (a,b). I have not tested this workaround.