- `cfg(target_has_atomic)` is stable now, use that.
- Hardcode in `build.rs` the list of targets with load/store but no CAS,
since `cfg(target_has_atomic_load_store)` is not stable yet.
- Do not try to autodetect whether `portable-atomic` is needed or not,
just let the user control it directly. If the user doesn't explicitly
enable `portable-atomic` and native atomics are unavailable, the
features requiring it will be missing.
from [this](https://doc.rust-lang.org/beta/unstable-book/compiler-flags/sanitizer.html#threadsanitizer)
> To work correctly ThreadSanitizer needs to be "aware" of all synchronization operations in a program. It generally achieves that through \[...\] and compile time instrumentation (e.g. atomic operations). Using it without instrumenting all the program code can lead to false positive reports.
and the example uses -Zbuild-std ... of course, std has to be instrumented. Adding -Zbuild-std fixes it, indeed.
the implementation uses a 64-bit atomic on `x86` to avoid the `ANCHOR` variable and the address
space limitation seen with the x86_64 compilation target
this PR also adds the i686-linux-musl target to the test matrix to exercise the new implementation
closes#231
