Uhg, gcc is doing the idiotic llvm thing of maximally-hoisting large stack usage, and also float usage (saving call-saved float regs). This surprisingly leads to hardfloat code SIGILL'ing on nofpu machines even when the float code is never reached.
-
-
Replying to @RichFelker
OOC why does this occur? Surely with nofpu you’re using a softfloat toolchain/switches so you emulate instead of SIGILL on FP instructions?
1 reply 0 retweets 0 likes -
Replying to @wattsamata
The issue was found by someone wrongly using an arm*eabihf toolchain on a chip without fpu and expecting it to work as long as no float code was invoked. This is not valid usage if the ABI does not mandate real or trap-and-emulate fpu insns be available. However...
1 reply 0 retweets 1 like -
Replying to @RichFelker @wattsamata
There are real-world archs (mips) where the normal ABI always has float registers/insns and kernel is expected to trap-and-emulate if hardware doesn't. GCC's bad hoisting (or failed shrinkwrap) here will make some code 5 orders of magnitude slower in code paths not using floats.
1 reply 0 retweets 1 like -
Replying to @RichFelker
Oh, so MIPS has no softfloat? OS is always expected to do no FP and also contain emulation support? Interesting. TIL :)
1 reply 0 retweets 0 likes
Traditionally, even with many chips not having full or any fpu, the only ABI was hardfloat. Then OpenWRT went and did a nonstandard softfloat thing to cut down kernel size (emulation code) but added same amt of code to userspace (or much more if anything's static linked).
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.