mk: Specify armv6 for gcc on arm-unknown-linux-*

[alexcrichton]

Right now the compiler's we're using actually default to armv7/thumb2 I believe,
so this should help push them back to what the arm-unknown-linux-* targets are
for. This at least matches that clang does for the arm-unknown-linux-gnueabihf
target which is to map it to an armv6 architecture.

Closes #31787

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[sanxiyn]

My understanding is that gnueabihf originated in Debian, and defined to allow ARMv7 and Thumb-2. If the platform does not support ARMv7 and Thumb-2, it should use gnueabi, not gnueabihf.

Rust can choose to interpret gnueabi/gnueabihf differently, but there should be a good reason to do so.

[alexcrichton]

I do think that many of our triples (especially these for embedded targets typically) are somewhat ad-hoc. Most of our "prior art" here in general has come from what clang does. The clang default cpu for this target is arm1136jf-s which is ARM v6 plus Thumb (not thumb2 I think).

[MagaTailor]

From that wiki:

Some concern for fast-enough, pretty awesome (600MHz+) ARMv6 + VFPv2 processors here - i.MX37 etc. - which will not be supported by armhf default flavour, but.. we will have to live with that

An entire distro cannot afford the level of backward compatibility a compiler, like rustc, can.

And besides we're mostly talking about compiler runtime here (and jemalloc) - the codegen options can still be tweaked with -C flags so there's not going to be a whole lot of difference on armv7 (as long as both ISAs remain hard-float).

[joerg-krause]

For llvm the default target for arm-unknown-linux-gnueabi is arm7tdmi, which is an ARMv4. However, rust tells llvm to use the v6 instructions: https://github.com/rust-lang/rust/blob/master/src/librustc_back/target/arm_unknown_linux_gnueabi.rs#L25.

As the ARM architecture is backward compatible maybe we should remove this restriction of setting v6 and rely to the compiler default.

[sanxiyn]

It is quite unfortunate that GCC and Clang disagree, but I guess following Clang is as good as any choice.

[lilydjwg]

I've verified this patch solves the issue I have, thanks!

[MagaTailor]

@joerg-krause
That's a good point! Now that there's a modern ARMv7 target and ARMv6-hf takes care of the original Rpi, the soft-float target should at least cater to armv5.

I remember your fixing the target in question so why not start a discussion in a dedicated issue or PR?

[brson]

@bors r+

[bors]

📌 Commit d4fda66 has been approved by brson

[joerg-krause]

@petevine I'll do it, if this comment gets accepted.

@alexcrichton Please consider to specify ARMv6 only for the hard-float target and specify as the default target architecture for the soft-float is the arm7tdmi CPU, which is an ARMv4. Or at least cater to ARMv5 as @petevine suggested. Note that the ARM architectures are backward-compatible.

[bors]

⌛ Testing commit d4fda66 with merge 3154ede...

[bors]

💔 Test failed - auto-linux-64-nopt-t

[alexcrichton]

@bors: retry

On Thu, Feb 25, 2016 at 8:26 AM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-linux-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-linux-64-nopt-t/builds/8174

—
Reply to this email directly or view it on GitHub
#31800 (comment).