> The chain:
>
> 6cc7df8e834 ("Remove left-overs of WIDEST_HARDWARE_FP_SIZE",
> 2026-07-04) deleted WIDEST_HARDWARE_FP_SIZE from alpha.h along with
> every other target. libgcc/libgcc2.h still keys
> AVOID_FP_TYPE_CONVERSION off that macro:
>
> #ifdef powerpc
> #define AVOID_FP_TYPE_CONVERSION(SIZE) (SIZE == 106)
> #elif defined(WIDEST_HARDWARE_FP_SIZE)
> #define AVOID_FP_TYPE_CONVERSION(SIZE) (SIZE > WIDEST_HARDWARE_FP_SIZE)
> #else
> #define AVOID_FP_TYPE_CONVERSION(SIZE) 0
> #endif
>
> so it silently became 0. F_MODE_OK(LIBGCC_TF_MANT_DIG) now succeeds,
> and __floattisf switched from the clz-based fallback to the TFmode
> path — _OtsCvtQX, _OtsMulX, _OtsAddX, then trunctfsf2. You can see it
> plainly in the disassembly: before the commit that function is the clz
> sequence, after it is three _Ots calls.
Sorry about that. I obviously had no idea that the WIDEST_HARDWARE_FP_SIZE
kludge had ever been used outside of the gcc/ directory (AFAICS since 2007).
> What is still open is the libgcc2.h side. No target defines
> WIDEST_HARDWARE_FP_SIZE any more — gcc/system.h poisons it — so that
> #elif branch is dead code for everyone, and every target that used to
> set it now silently takes the wide-FP path in __float{,un}ti{sf,df}.
> rs6000 is unaffected (the powerpc branch wins), but alpha,
> i386/x86_64, sparc, pa, s390, aarch64, visium and ia64-vms all changed
> behavior. I checked x86_64 directly: in gcc 15's libgcc, __floattisf,
> __floattidf, __floatuntisf and __floatuntidf are self-contained, and
> on trunk each of them now calls out to __floatditf/__floatunditf,
> __multf3, __addtf3 and __trunctfsf2/ __trunctfdf2 — five soft-float
> calls per conversion where there were none. Those targets stay
> correct, since soft-fp rounds once; only alpha turned it into a
> wrong-answer bug, because only alpha narrows TF->SF through DF.
Curious that nothing popped up in the compiler testsuites for i386/x86_64,
sparc, or aarch64, which are actively tested, and that only the alpha bug
uncovered it instead. Thanks for catching and analyzing the problem!
> So I think there are two things to settle, independent of my
> trunctfsf2 fix (which should stay regardless — glibc hits it):
>
> - whether that dead #elif should just be deleted, accepting the
> wide-FP path everywhere, or whether the intent should be restored
> under a name libgcc can still see. The mechanism that already exists
> for this is the _LIBGCC* builtin macros, so an explicit one for
> libgcc's use would be the tidy version. Given the x86_64 numbers
> above, "just delete it" has a real cost on the most common target, not
> a hypothetical one.
Yes, we should repair the damages, probably with a new macro that does not
refer to the hardware but rather describes what it actually does, possibly
reusing AVOID_FP_TYPE_CONVERSION directly.
> - whether alpha in particular wants the fallback back. The TF path is
> correct now but it is three out-of-line calls into libc's _Ots
> routines where the fallback is a handful of inline instructions.
This looks clear to me according to your description.
--
Eric Botcazou
