__aeabi_ functions should use the AAPCS calling convention, at least with LLVM 4.0+

[rust-lang]

__aeabi_ functions should use the AAPCS calling convention, at least with LLVM 4.0+

[japaric]

I think the __aeabi aliases should use the AAPCS calling convention

Yes or we'll hit the floatundidf bug when we integrate this into rust-lang/rust.

If the functions that are being aliased don't also use extern "aapcs"

The "aliased" functions must also use extern "aapcs"

This may me realize that we may be invoking the functions in libcompiler-rt.a with the wrong calling convention. We are calling them as if they were extern fns when we should be using extern "aapcs" fn instead. I expect this would cause problems for the arm-gnueabihf target. Have we had problems with that target?

[mattico]

From the discussion above, I gather:

Lib	eabi	rest
gcc_s	aapcs	c
compiler-rt	aapcs	c
compiler-rt 4.0	aapcs	aapcs
compiler-builtins	c	c

[TimNN]

Note that for rust currently aapcs == c. Also, in llvm, there are actually aapcs and aapcs-vfp, where the vfp version is hard float and the "normal" version is soft float. Then, for llvm, c is aapcs on soft float targets and aapcs-vfp on hard float targets.

Af far as I can tell, in Rust there is currently no way to specify aapcs (not vfp) on armhf targets.

The only thing that changes for llvm 4.0, I think, is that the powi intrinsic now requires aapcs (no hf) now as well (it previously did not). This as been reported as a regression to llvm (https://llvm.org/bugs/show_bug.cgi?id=30543).

[japaric]

@mattico FYI: extern "aapcs" fn should be fixed in recent nightlies, if you want to give this another try.

[mattico]

Is there a better way to solve this than using a macro for every extern fn declaration?

[japaric]

This may me realize that we may be invoking the functions in libcompiler-rt.a with the wrong calling convention

To clarify: I meant in our unit tests. We have a transmute from usize to extern fn.

[mattico]

Have we had problems with that target?

Yes, this seems very likely to be causing #90 and the issues in #106.

To clarify: I meant in our unit tests. We have a transmute from usize to extern fn.

If I recall correctly, the issues only occurred inside the unit tests not when called normally, which makes sense.

I'll go test this theory right now.

[mattico]

I tested this by making everything extern "aapcs" and making sure the compiler-rt submodule included the aapcs changes and it didn't fix anything. I'm probably just missing something since this still seems like the most likely culprit.

https://github.com/mattico/compiler-builtins/tree/aapcs

[japaric]

I don't think changes like these are correct:

fn __addsf3(f: extern "aapcs" fn(f32, f32) -> f32,

I think the intrinsics in libgcc.a are compiled the "hard" calling convention (not aapcs) so those should be called using extern "C" fn. I also think that extern "aapcs" fn doesn't make a difference over extern "C" fn in functions that don't take or return floating point values.

[parched]

Af far as I can tell, in Rust there is currently no way to specify aapcs (not vfp) on armhf targets.

Does extern "aapcs" fn not work?

This as been reported as a regression to llvm

It's not clear to me whether that is a regression or improvement. I think it's regression but the compiler-rt guy thinks that's how it should be.

[TimNN]

Af far as I can tell, in Rust there is currently no way to specify aapcs (not vfp) on armhf targets.

Does extern "aapcs" fn not work?

No, from the rust source:

Aapcs => llvm::CCallConv,

[japaric]

Aapcs => llvm::CCallConv,

Is that a bug? With that extern "aapcs" fn would be no different than extern "C" fn then ...

[TimNN]

Is that a bug? With that extern "aapcs" fn would be no different than extern "C" fn then ...

Well, there's the comment // These API constants ought to be more specific... just above...

I would assume that this was the easy way of getting the correct aapcs version (soft vs hard float) without having to add that logic to rustc.

[parched]

Yes definitely a bug and the reason the @mattico's test failed.

[parched]

Bug report here rust-lang/rust#37810