fetch_max broken for atomici8 and atomici16 on some targets.

[plugwash]

The rust atomic crate was recently uploaded to Debian, unfortunately on a number of Debian architectures it's tests failed.

---- tests::atomic_i16 stdout ----
thread 'tests::atomic_i16' panicked at 'assertion failed: `(left == right)`
  left: `-25`,
 right: `30`', src/lib.rs:448:9

---- tests::atomic_i8 stdout ----
thread 'tests::atomic_i8' panicked at 'assertion failed: `(left == right)`
  left: `-25`,
 right: `30`', src/lib.rs:428:9

The debian architectures where it failed and the corresponding rust architectures are listed below.

armel -> armv5te-unknown-linux-gnueabi
mips64el -> mips64el-unknown-linux-gnuabi64
mipsel -> mipsel-unknown-linux-gnu
powerpc -> powerpc-unknown-linux-gnu

My guess is that this is a bug in fallback code used when the architecture does not natively support 8 and 16 bit atomics.

I produced the following testcase to confirm this was not a problem in the atomic crate, but instead an issue in either the compiler or the standard library. I tested this on Debian armel.

use std::sync::atomic::Ordering::SeqCst;
use std::sync::atomic::AtomicI8;
use std::sync::atomic::AtomicI16;
use std::sync::atomic::AtomicI32;
fn main() {
    let a = AtomicI8::new(30);
    println!("{}",a.fetch_max(-25,SeqCst));
    println!("{}",a.load(SeqCst));
    let a = AtomicI16::new(30);
    println!("{}",a.fetch_max(-25,SeqCst));
    println!("{}",a.load(SeqCst));
    let a = AtomicI32::new(30);
    println!("{}",a.fetch_max(-25,SeqCst));
    println!("{}",a.load(SeqCst));
}

I expected this to print 30 six times, but the second and fourth lines of the output are instead -25, this shows fetch_max is not being implemented correctly for AtomicI8 and AtomicI16 (but is being implemented correctly for AtomicI32).

I've only tested this with Debian's rustc so far, I may try to test with upstream rustc but this is complicated by the fact that I don't think upstream offers binaries for armv5te-unknown-linux-gnueabi

Meta

rustc --version --verbose:

rustc 1.59.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: armv5te-unknown-linux-gnueabi
release: 1.59.0
LLVM version: 13.0.1

[workingjubilee]

I've only tested this with Debian's rustc so far, I may try to test with upstream rustc but this is complicated by the fact that I don't think upstream offers binaries for armv5te-unknown-linux-gnueabi

Correct, unfortunately. This will likely require building from source.
Please feel free to open any issues you run into if you do that.
Also, we currently use a version of LLVM 15, recently upgraded from LLVM 14. It would be useful to know if using the old LLVM is what decides the matter.

Unfortunately, LLVM has reduced their support for atomics on some platforms, and Rust attempts to avoid exposing anything but hardware atomics, so there might even be flat-out regressions on some of these: #99668

[workingjubilee]

Also:

armv5te-unknown-linux-gnueabi

This is in fact a tier 2 platform, apparently, so we do distribute std for this target and you can cross-compile for it.

[Amanieu]

LLVM bug: llvm/llvm-project#61880

[Amanieu]

And 2 more LLVM bugs in the MIPS and PowerPC backends:

• [MIPS] Incorrect expansion of sub-word signed atomic max llvm/llvm-project#61881
• [PowerPC] Missing sign extension in expansion of sub-word atomic max llvm/llvm-project#61882