1.27.1 armv5te-unknown-linux-gnueabi many atomic tests fail

[infinity0]

See https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=armel&ver=1.27.1%2Bdfsg1-1%7Eexp1&stamp=1531907232&raw=0 near the bottom, sample:

test num/mod.rs - sync::atomic::AtomicI16::fetch_max (line 210) ... FAILED
test num/mod.rs - sync::atomic::AtomicI16::fetch_max (line 223) ... FAILED
test num/mod.rs - sync::atomic::AtomicI16::fetch_min (line 210) ... FAILED
test num/mod.rs - sync::atomic::AtomicI16::fetch_min (line 225) ... FAILED
[..]

[infinity0]

0f5e419

@llogiq Are your new tests supposed to work on armv5te or should they just be ignored?

[llogiq]

Interesting. It seems the platform doesn't implement the atomic operations. I'd suggest either removing the operations entirely for armv5te or special-case the platform using a simple CAS loop implementation.

[infinity0]

What's the smallest patch in Debian I should make to 1.27.1 to deal with this? If we simply remove the operations then some stuff won't compile on armv5te right?

[llogiq]

I think I should be able to make a PR with a small set of changes you can backport. Again, I'd simply #[cfg(..)] out the intrinsics and put a naive CAS loop instead. The only thing I'll have to figure out is what to put in the #[cfg(..)].

[llogiq]

In the meantime, you might change the innards of fetch_max/fetch_min (line 1515 and 1556) with

                pub fn fetch_max(&self, val: $int_type, order: Ordering) -> $int_type {
                    self.fetch_update(|v| Some(v.max(val)), order, order).unwrap()
                }

(and replace the "max" with "min" for fetch_min). Then remove the atomic_min/atomic_max functions, as they are no longer needed.

[mati865]

@infinity0 is this issue resolved by merging the patch from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906520 in rust-lang/compiler-builtins#255?

[infinity0]

@mati865 yes exactly, I'll close it.