After starting over with the x-tools C++ crosscompiler to build my Raspi apps, I found out that the app runs considerably (approx. 1/3) slower than when built with the g++ (version 6.5.0) on the Raspi. Running g++ -Q --help=target made me suppose that the crosscompiler (version 8.3.0) omits the FPU on the Raspi:

g++ on the Raspi:

-mfloat-abi=                          hard
-mfp16-format=                        none
-mfpu=                                vfp

Crosscompiler on my Ryzen workstation:

-mfloat-abi=                          soft
-mfp16-format=                        none
-mfpu=                                auto

Does that mean that floating-point numer ops are soft-coded in the machine code from the crosscompiler despite the fact that the Raspi does feature an FPU?

UPDATE: After following the ARM hard float doc, I tried these tags both in the compiler, and the linker:

-mfpu=vfp -mfloat-abi=softfp

Now the genuine g++ on the Pi refused to compile. The crosscompiler did work, but I can't see any differences compared to the previous config (without the FPU and ABI flags). -mfloat-abi=softfp did not work, though.


2 Answers 2


Note that building soft float SW for Pi OS is not just a missed optimization opportunity, it's a mistake: system libraries are built with hard float ABI and expect float variables in FPU registers. You are apparently not using any such libraries, otherwise your SW would likely crash when you run it on a Pi.

  • This puzzles me even more as I copied the necessary libs (there were > 40 of them, including GeographicLib, which definitely uses hard floats) from the Pi into my x-tools environment, so if they required hard floats, my app wouldn't even compile with the crosscompiler, right?
    – Neppomuk
    Mar 10, 2021 at 18:45
  • @Neppomuk It would compile. The crash happens at runtime, when you call a function with an argument in the FPU register, and the function expects it to be on the stack. Mar 10, 2021 at 22:40
  • 1
    In fact, it did even run without crashing, but at a snail's speed. Supposedly I do have soft-float versions of the necessary libs on my Pi, but relying on soft-float is simply counterproductive.
    – Neppomuk
    Mar 11, 2021 at 20:57
  • @Neppomuk Not many libs use floats in the first place, OpenGL/GLM, GSL, LAPACK/LINPACK and BLAS come to mind. Mar 12, 2021 at 14:33
  • GeographicLib not?
    – Neppomuk
    Mar 12, 2021 at 21:02

After looking into the options of ct-ng menuconfig for a second time, I found out what had prevented the crosscompiler from building hard-float code: a missing FPU option! There are two options (one for the PF / SIMD unit) and one for hard-float vs. soft-float. Both must be activated manually:

Target options

The new compiler's name is: arm-unknown-linux-gnueabihf-g++

After building the toolchain with both options set as displayed in the screenshot, everything compiles and links well, and the machine code runs at "native" speed.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.