compiler-builtins VS libm

I don't know which symbols are missing, haven't done anything on the llvm level. But I had the same problems creating a no-std no-libc application, if you add https://github.com/rust-lang/compiler-builtins as a dependency you should get all the symbols you need, std uses the same but if you want to use it outside of std you'll need nightly since it uses a lot a nightly features. It might apply to your case as well.

Ah, I see - you might be hitting https://github.com/rust-lang/compiler-builtins/issues/347.

There's a PR to the compiler-builtins crate which the rust implementation is based on.

I'm glad to inform y'all that after a year, the infamous LLVM ERROR: Not supported instr bug¹ has been finally fixed and today's nightly can compile for AVR back again! 😎

Then, some of the non-trivial things that are needed are already implemented and maintained in other crates, like memcpy and friends in compiler-builtins, all the math routines in libm and malloc in dlmalloc.

3.Use scons to compile, if errors jumped on link up, find the solution on its official Github.

Yes I took a look at build.rs. There's nothing here that stands out to me. Building the project on my Ubuntu machine works btw.

The more interesting code is the "kernel" tangent function https://github.com/rust-lang/libm/blob/master/src/math/k_tan.rs . I don't see any numerical analysis of accuracy in either the Rust lib or the MUSL source lib, but from one of the comments it looks like it's intended to be within 1ULP, which is what I'd expect.

It's nowhere near complete, but: https://github.com/rust-lang/libm

Inaccurate fast implementations use polynomial approximation. Accurate implementations use high-powered argument reduction and then polynomial approximation. Everything is polynomial approximation.

It looks like https://github.com/rust-lang/libm/pull/249 may be a fix for this.

In order to be standards-compliant, computer math libraries need to have a lot more digits of pi than should be strictly necessary. Accurately calculating sine in the upper reaches of double precision floats requires computer to have a table of about 100 digits of pi (or rather pi/2 for technically reasons) and 500 digits of 2/pi - here is an example.

So, fixed-point numbers weren't the solution to the problem either. The next thing I came across was the Rapier physics engine. It promises cross-platform determinism all IEEE 754-2008 compliant platforms. Although it's written in Rust, creating C# bindings was fairly easy, and I could use it in Unity after a few hours. But Rapier is still in early stages of development, which means that (at the time of writing this) it lacked many features, like raycasting, which would have been necessary for my project. Also, it's only deterministic on IEEE 754-2008 compliant platforms. But I couldn't really find any information on which processors support it. Even if I did, I still wanted to have deterministic physics on all platforms, not just on "most of them". But I still wondered does how Rapier achieve cross-platform floating point determinism. Supporting only IEEE 754-2008 compliant platforms is one thing, but the mathematical functions I mentioned above (sqrt, trigonometry, etc.) must also be deterministic. I found out that it uses libm, which implements all of these functions in software. It was primarily designed for embedded systems without FPUs, but it turns out it's also pretty useful for making this part of floating point math deterministic. But after all, the basic mathematical operations of floats are still not deterministic. Unless... How about emulating the behavior of floats in software? It should be possible to write a program that works on the byte representation of a float, doing all operations using integer arithmentic... right?