Unaligned load/store regression - ARMv5 incorrect codegen

[arcnmx]

#23431 is back, the test case from that issue now miscompiles on ARMv5 again. This broke somewhere between the Jan 3rd and March 9th nightlies.

main.rs and main.ll

[arcnmx]

CC @dotdash - you identified and fixed this issue the last time it came up, any ideas about what changed recently that brought it back?

[dotdash]

No idea. A cursory glance at the IR doesn't show up any missing alignment specifiers either.

[arcnmx]

main.ll from old nightly + diff

The bizarre thing is that I don't see any real differences besides the identifier hashes in that diff... That nightly does indeed generate a working binary though. Function attribute differences? These are both opt-level=3 lto. Should I compare the asm I guess?

EDIT: less noisy IR diff

[arcnmx]

Generated asm from both + diff: http://pastie.org/private/j5onpivq1disqrrnwy9pq

[arcnmx]

Okay, I've bisected across rustc versions...

Nightly 2016-01-30 303892ee1 works, 2016-01-31 9a07087bc is broken.

303892e...9a07087 ... and I see no changes to trans at all there ;_;

[joerg-krause]

@arcnmx Are you using a custom JSON target file for ARMv5?

[arcnmx]

@joerg-krause yeah, there's no built-in target for it in rustc.

[arcnmx]

Okay I appear to have messed up... It's actually jan 28 vs 30 (there is no 29 nightly): 38e23e8...303892e

[joerg-krause]

The issue you describe is about faulty data alignment. You have to tell LLVM to compile with strict-align option:

"features": "+v5te,+dsp,+soft-float,+strict-align,-crypto,-neon"

Have a look at my armv5te-unknown-linux-gnueabi for comparison.

[joerg-krause]

Note, you'll have to recompile the rust libs after changing the target configuration.

[arcnmx]

@joerg-krause makes sense, thanks! Especially alongside the LLVM version update in the commit range I linked. Will try and report back.

[joerg-krause]

For the record, this issue #31796 was related to faulty data alignment, too.

[arcnmx]

Yup, that seems to help, thanks! strict-align seems to be a new target feature in the updated LLVM... and of course they helpfully removed the logic that used to infer it from the CPU architecture...