Pararrer codegen + NEON vector instructions = crashing code

[MagaTailor]

On ARM, I had a crashing exa -l binary and was going to chalk it up to buggy or miscompiled llvm.
It turned out, however, it was the combination of -C codegen-units and +neon that was producing broken code. Turn off either of them and all's fine again.

I believe parallel codegen is a Rust feature so maybe it's a case of LLVM being used improperly on ARM?

Full command line:
-C target-cpu=cortex-a5 -C target-feature=+vfp4,+neon -C llvm-args=-force-target-max-vector-interleave=4 -C codegen-units=4 -C link-args=-s

rustc 1.9.0-dev (1a019dc86 2016-03-11)
binary: rustc
commit-hash: 1a019dc86de1459809f776b869e36f8e71a7665a
commit-date: 2016-03-11
host: arm-unknown-linux-gnueabihf

[MagaTailor]

After some more investigation:

$ gdb --args exa -l ~/
Program received signal SIGILL, Illegal instruction.
0xb6e84268 in ?? () from /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
(gdb) c
Continuing.

Program received signal SIGBUS, Bus error.
0x7f5dbd94 in exa::options::Options::getopts::h06436b42770af21e ()
(gdb) bt
#0  0x7f5dbd94 in exa::options::Options::getopts::h06436b42770af21e ()
#1  0x7f5b953c in exa::main::h4671dcdc83e99fa9 ()
#2  0x7f658930 in std::sys_common::unwind::try::try_fn::h0f540c0db5f980f7 ()
#3  0x7f661f48 in std::sys_common::unwind::inner_try::h74a189ca1fbe8e07 ()
#4  0x7f65844c in std::rt::lang_start::h7bd5d5e5d238827f ()
#5  0xb6d17632 in __libc_start_main (main=0x7f5babe4 <main>, argc=3, argv=0xbeffee54, init=<optimized out>, fini=0x7f6749bd <__libc_csu_fini>, 
    rtld_fini=0xb6fea4c5 <_dl_fini>, stack_end=0xbeffee54) at libc-start.c:287
#6  0x7f5b7114 in _start ()

The first part is just doing available instruction sets detection so it should be ignored .
It looks like that memory error is caused by miscompilation (and not application error) but the funny thing is redirecting program output to a file suddenly works fine again.

@ogham Any idea if it could be some sort of ARM specific Linux bug in exa that's somehow triggered by optimizations?
Here's a system trace gist

[MagaTailor]

@japaric I've just downloaded the official armv7 nightly rustc binary and the issue reproduces just fine.
Here's a better trace:

Program received signal SIGSEGV, Segmentation fault.
exa::options::{{impl}}::deduce::{{closure}} () at src/options.rs:181
181                         recurse: dir_action.recurse_options(),
(gdb) bt
#0  exa::options::{{impl}}::deduce::{{closure}} () at src/options.rs:181
#1  exa::options::{{impl}}::deduce (matches=<optimized out>, dir_action=..., 
    filter=...) at src/options.rs:291
#2  exa::options::{{impl}}::deduce (matches=<optimized out>)
    at src/options.rs:133
#3  exa::options::{{impl}}::getopts (args=...) at src/options.rs:113
#4  0x7f55ed8c in exa::main () at src/main.rs:145
#5  0x7f6051d0 in std::sys_common::unwind::try::try_fn::h76efc8ed010787e5 ()
#6  0x7f60167c in __rust_try ()
#7  0x7f604bfc in std::rt::lang_start::h73c48c6a9af036ed ()
#8  0xb6d09632 in __libc_start_main (main=0x7f560314 <main>, argc=2, 
    argv=0xbeffee44, init=<optimized out>, fini=0x7f7fa96d <__libc_csu_fini>, 
    rtld_fini=0xb6fea4c5 <_dl_fini>, stack_end=0xbeffee44) at libc-start.c:287
#9  0x7f55be70 in _start ()

[MagaTailor]

After the exa refactor, debug + optimizations produces some more info, this time neon memcpy is explicitly hit, probably starting at # 4:

Program received signal SIGSEGV, Segmentation fault.
__memcpy_neon () at ../ports/sysdeps/arm/armv7/multiarch/memcpy_impl.S:749
749     ../ports/sysdeps/arm/armv7/multiarch/memcpy_impl.S: No such file or directory.
(gdb) bt
#0  __memcpy_neon () at ../ports/sysdeps/arm/armv7/multiarch/memcpy_impl.S:749
#1  0x7f57ddbc in exa::options::view::{{impl}}::deduce (
    matches=<optimized out>, filter=..., dir_action=...)
    at src/options/view.rs:173
#2  0x7f5840bc in exa::options::{{impl}}::deduce (matches=0xbeffd568)
    at src/options/mod.rs:140
#3  0x7f55fe4c in exa::options::{{impl}}::getopts<collections::string::String>
    (args=...) at src/options/mod.rs:120
#4  0x7f55b23c in exa::{{impl}}::new<std::io::stdio::Stdout,collections::string::String> (
    args=<error reading variable: access outside bounds of object referenced via synthetic pointer>, writer=<optimized out>) at src/exa.rs:56
#5  exa::main () at src/bin/main.rs:12
#6  0x7f607334 in std::sys_common::unwind::try::try_fn::h9c7a855073631f82 ()
#7  0x7f603824 in __rust_try ()
#8  0x7f606d54 in std::rt::lang_start::h801b666f82634252 ()
#9  0xb6d17632 in __libc_start_main (main=0x7f5789d4 <main>, argc=2, 
    argv=0xbeffee34, init=<optimized out>, fini=0x7f61dbf5 <__libc_csu_fini>, 
    rtld_fini=0xb6fea4c5 <_dl_fini>, stack_end=0xbeffee34) at libc-start.c:287
#10 0x7f55af6c in _start ()

[MagaTailor]

@ogham I've traced the issue down to opt-level=3 used in exa's Cargo.toml. Until this is properly fixed, I suggest downgrading to opt-level=2.

[MagaTailor]

Closing in favour of the more focused #33181