On 8/9/2026 9:45 PM, Matt Turner wrote:
[ Big snip ]
Tracked it down. Short version: the tests are already green again on
trunk as of yesterday, but for a reason unrelated to what actually
broke them, and the real fallout is still there.
Yea, my alpha run with your patch spun a couple days ago and was
successful.
It is not a codegen change in the tests — the test .o is
byte-identical across the whole range. It is libgcc. Linking the same
object against each build's libgcc.a flips the result, and it narrows
to _floatdisf.o and _floatundisf.o, i.e. __floattisf and
__floatuntisf.
I "love" these... In fact, I'd been putting off debugging a sh4
bootstrap failure because I suspected it might fall into this bucket.
Thankfully Jakub's fixes to some recent ranger work has sh4 building again..
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.
Ah! I didn't really expect your patch to fix those regressions, but
happy it did.
- 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.
Yea, we clearly have something to clean up here.
- 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.
No strong opinion there.
Thanks again for chasing this down!
Jeff
