Rollup merge of #42314 - jannic:patch-1, r=japaric

ARMv5 needs +strict-align

Without that flag, LLVM generates unaligned memory access instructions, which are not allowed on ARMv5.

For example, the 'hello world' example from `cargo --new` failed with:
```
$ ./hello
Hello, world!
thread 'main' panicked at 'assertion failed: end <= len', src/libcollections/vec.rs:1113
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```

I traced this error back to the following assembler code in `BufWriter::flush_buf`:
```
    6f44:       e28d0018        add     r0, sp, #24
[...]
    6f54:       e280b005        add     fp, r0, #5
[...]
    7018:       e5cd001c        strb    r0, [sp, #28]
    701c:       e1a0082a        lsr     r0, sl, #16
    7020:       03a01001        moveq   r1, #1
    7024:       e5cb0002        strb    r0, [fp, #2]
    7028:       e1cba0b0        strh    sl, [fp]
```

Note that `fp` points to `sp + 29`, so the three `str*`-instructions should fill up a 32bit - value at `sp + 28`, which is later used as the value `n` in `Ok(n) => written += n`. This doesn't work on ARMv5 as the `strh` can't write to the unaligned contents of `fp`, so the upper bits of `n` won't get cleared, leading to the assertion failure in Vec::drain.

With `+strict-align`, the code works as expected.

src/librustc_back/target/armv5te_unknown_linux_gnueabi.rs

@@ -25,7 +25,7 @@ pub fn target() -> TargetResult {
         linker_flavor: LinkerFlavor::Gcc,
 
         options: TargetOptions {
-            features: "+soft-float".to_string(),
+            features: "+soft-float,+strict-align".to_string(),
             // No atomic instructions on ARMv5
             max_atomic_width: Some(0),
             abi_blacklist: super::arm_base::abi_blacklist(),