[LittlePyx]

On AVX2, sorting {+0.0, +0.0, +0.0, +0.0, -0.0} with x86simdsort::qsort produces four negative zeros in ascending order and none in descending order. Both results should contain exactly one negative zero. This addresses the x86 case reported in numpy/numpy#33286.

When two lanes compare equal, x86 floating-point min and max both select their second operand. For independent registers, the sorting network now uses min(a, b) and max(b, a) so each input contributes once. A mirrored merge already compares each pair in both lane orders and takes one lane from each result, so it keeps the original operand order. The change applies only to native floating-point comparisons.

Validation

• AVX2 hardware — On a Ryzen 7 5800H with GCC 13.3, the new C++ regression test calls the public qsort API in both directions at lengths 5 and 17. All four cases failed on the original code and passed with the fix. The full GoogleTest suite passed (394 tests, zero skips).
• AVX2 performance — For ascending sorts of 128 random int32 values, median runtime differed from upstream by −0.63% to +0.97% across three input seeds and two library load orders.
• AVX-512 emulation — Under Intel SDE 9.58, all 2,640 checks preserved the input bit patterns and their counts across sort, select, and partial sort on the Skylake-X, Tiger Lake, and Sapphire Rapids models. Coverage included native FP16 on Sapphire Rapids. These were correctness checks.

AI disclosure

Codex assisted with writing and testing the patch and drafting this PR description.

[r-devulap]

On AVX2, sorting {+0.0, +0.0, +0.0, +0.0, -0.0} with x86simdsort::qsort

is this AVX2 specific? Sounds like this should be true on AVX-512 as well, right?

[LittlePyx]

Yes, I reproduced the signed-zero count issue on AVX-512 as well. I tested AVX2 on a Ryzen 7 5800H and AVX-512 under Intel SDE 9.58 using the Skylake-X model. In the AVX-512 run, the original code changed the zero counts for both float and double. With the patch, the same cases preserved the counts.

[r-devulap]

This problem exists for all 3 floating point types: _Float16, float and double. Can you extend these tests for these types too?

[LittlePyx]

Thanks for pointing this out. In 00d7c7c I extended the regression test to _Float16, float, and double in both sort directions. I added a 33-element case because the original lengths (5 and 17) passed for _Float16 even with the old code. Under Intel SDE on the Sapphire Rapids model, all three typed tests failed against the original library and passed with the fix.

[r-devulap]

Can we move this logic into the original COEX definition? You would have to pass mirrored template argument in there but that should be easy. It keeps tie-breaking logic in one place.

[LittlePyx]

Moved the floating-point tie handling into the original COEX in 23419ef. The comparator now forwards the policy and swaps the arguments for descending order. The signed-zero tests for _Float16, float, and double passed under Sapphire Rapids emulation.

[r-devulap]

Suggest renaming mirrored to keep_lane_on_tie?

[LittlePyx]

Renamed it to keep_lane_on_tie in 23419ef. It defaults to true for independent registers, including pivot sampling. Only the reverse-and-merge and swap-and-merge calls pass false: those compare each pair in both lane orders before blending.

[r-devulap]

We dont need a new class, you can use the existing simdsort class and run the test conditional on floating point:

Suggested change

	TYPED_TEST(FloatingPointQSort, preserves_signed_zeros)
	TYPED_TEST_P(simdsort, preserves_signed_zeros)
	{
	if constexpr (xss::fp::is_floating_point_v<TypeParam>) {

[LittlePyx]

Thanks for the suggestion. In d9b4824 I moved the test into the existing simdsort suite, guarded it with if constexpr (xss::fp::is_floating_point_v<TypeParam>), and removed the separate fixture and type list. Under Sapphire Rapids emulation, all three floating-point cases still fail against the original library and pass with the fix.