[thejpster]

These two targets currently force on the LLVM feature +atomics-32. LLVM doesn't appear to actually be able to emit 32-bit load/store atomics for these targets despite this feature, and emits calls to a shim function called __sync_lock_test_and_set_4, which nothing in the Rust standard library supplies.

See #t-compiler/arm > __sync_lock_test_and_set_4 on Armv5TE for more details.

Experimenting with clang and gcc (as logged in that zulip thread) shows that C code cannot do atomic load/stores on that architecture either (at least, not without a library call inserted).

So, the safest thing to do is probably turn off +atomics-32 for these two Tier 3 targets.

I asked @Lokathor and he said he didn't even use atomics on the armv4t-none-eabi/thumbv4t-none-eabi target he maintains.

I was unable to reach @QuinnPainter for comment for armv5te-none-eabi/thumbv5te-none-eabi.

The second commit renames the base target spec spec::base::thumb to spec::base::arm_none and changes armv4t-none-eabi/thumbv4t-none-eabi and armv5te-none-eabi/thumbv5te-none-eabi to use it. This harmonises the frame-pointer and linker options across the bare-metal Arm EABI and EABIHF targets.

You could make an argument for harmonising armv7a-none-*, armv7r-none* and armv8r-none-* as well, but that can be another PR.