https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91970
--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- Arm only uses soft-fp for Thumb-1; otherwise it uses Arm-specific assembly code. A natural fix might be, for these particular functions, in the hard-float case, to use the libgcc2.c versions instead; I expect that's faster than doing them entirely as software floating-point while respecting exceptions and rounding modes. Arguably for the other functions, in the hard-float case, it would be best to build the t-hardfp versions to keep the libgcc size down, instead of the assembly versions. In both cases you'd need to make sure the functions have the ABI-specified names, that they get properly built for the base PCS rather than the VFP variant, where the ABI requires that, and that any other ABI requirements are met (the default libgcc versions, compiled as C code, might not always follow the same interface as the ABI-defined functions). The only case where soft-fp support for exceptions and rounding modes seems likely to be useful for Arm is those processors that do single-precision-only floating point in hardware, for which use of soft-fp for double precision would make sense in order to support exceptions and rounding modes (along with t-hardfp for single precision). (Also, I suppose, use of soft-fp with exceptions and rounding modes would make sense for half-precision on hardware with floating-point support only for single and maybe double precision.)
