Re: [PATCH] alpha: round to odd before narrowing TFmode to SFmode

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