don't override arm calling convention

[TimNN]

This should fix rust-lang/rust#37559.

With that line, the generated code transfers arguments / return value in r0, r1 / r0.

Without that line, the generated code transfers the arguments / return value in s0, r0 / s0.

I have no idea how this change will impact other builtins or targets other than armv7-unknown-linux-gnueabihf.

Tested with arm-linux-gnueabihf-gcc on Ubuntu.

cc @alexcrichton, @japaric, @nagisa

[japaric]

👍 to removing the attribute.

Context (for posteriority):

• The AAPCS (ARM Architecture Procedure Calling Standard) standard has a variant aapcs-vfp that allows passing/returning floating point values through the FPU registers (s0/d0). (See section 6.1.2.1 of the linked document). (The alternative, aapcs, is to pass/return the floating point values through the processor registers (r0))
• Rust / LLVM is using aapcs-vfp for hard float targets.
• compiler-rt is forbidding the use of this variant with the pcs(aapcs) attribute. This what the gcc documentation says:

The pcs attribute can be used to control the calling convention used for a function on ARM. The attribute takes an argument that specifies the calling convention to use.

When compiling using the AAPCS ABI (or a variant of it) then valid values for the argument are "aapcs" and "aapcs-vfp". In order to use a variant other than "aapcs" then the compiler must be permitted to use the appropriate co-processor registers (i.e., the VFP registers must be available in order to use "aapcs-vfp").

• With this change both Rust and compiler-rt will agree on the calling convention.
• Why not change Rust to aapcs, instead? Because the whole point of the hard float ABI is to be able to use the aapcs-vfp calling convention! Otherwise there wouldn't exist two different float ABIs.

[japaric]

I have no idea how this change will impact other builtins or targets other than armv7-unknown-linux-gnueabihf.

We should check that the intrinsics when compiled for arm-unknown-linux-gnueabi (note no hf) still use the soft float / aapcs calling convention as a sanity check.

[TimNN]

Compiling powisf2.c with the (Ubuntu supplied) arm-linux-gnueabi-gcc without the COMPILER_RT_ABI produces this assembly, which is the same as the one produced with COMPILER_RT_ABI.

---

Just to make sure, could this change impact ios / android? (I think not because I guess __ARM_EABI__ is only defined for the gnueabi targets?)

[alexcrichton]

Wow, thanks for the explanation @japaric and investigation @TimNN! Agreed that this will likely only impact the linux targets due to the EABI business. We can tweak that later if necessary, though, for Android/iOS