u64x4::clamp producing unexpected and incorrect results

[Jacherr]

It has been observed that, at least on x86 systems, the usage of std::simd::u64x4::clamp may cause undefined behaviour under seemingly random conditions, or at least may not function properly.

The issue can be reproduced in the Rust Playground (Edit: in both debug and release modes):

#![feature(portable_simd)]
use std::simd::*;
fn main() {
    let x = u64x4::from_array([10,1,1,1]);
    let y = x.clamp(u64x4::splat(0), u64x4::splat(9));
    let z = y.as_array();
    dbg!(z);
}

I expected this code to produce a result of [9, 1, 1, 1].
The code, in my testing, instead produced a result of [9, 9, 9, 9].

#![feature(portable_simd)]
use std::simd::*;
fn main() {
    let x = u64x4::from_array([1,1,1,10]);
    let y = x.clamp(u64x4::splat(0), u64x4::splat(9));
    let z = y.as_array();
    dbg!(z);
}

This example should have produced a result of [1, 1, 1, 9].
It instead produced a result of [1, 1, 1, 10].

Meta

rustc --version --verbose:

rustc 1.61.0-nightly (10913c000 2022-03-03)
binary: rustc
commit-hash: 10913c00018c76103b2fd4260d8c02ec728fd244
commit-date: 2022-03-03
host: x86_64-unknown-linux-gnu
release: 1.61.0-nightly
LLVM version: 14.0.0

[programmerjake]

that's because clamp is currently only implemented for floats. you're getting Ord::clamp instead, which is giving the correct results (since it lexicographically compares the vectors and returns one of the input vectors, rather than the element-wise clamp your expecting).

[programmerjake]

this is nearly identical to what's happening in #247

we need to add clamp (and min/max) functions for integer vectors.