[PATCH 37/59] math: Fix modf{f} build on clang

[H.J. Lu]

On Fri, Oct 24, 2025 at 5:38 AM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 23/10/25 18:27, H.J. Lu wrote:
> > On Thu, Oct 23, 2025 at 10:00 PM Adhemerval Zanella Netto
> > <adhemerval.zanella@linaro.org> wrote:
> >>
> >>
> >>
> >> On 22/10/25 18:51, H.J. Lu wrote:
> >>> On Thu, Oct 23, 2025 at 12:26 AM Adhemerval Zanella Netto
> >>> <adhemerval.zanella@linaro.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 20/10/25 19:09, H.J. Lu wrote:
> >>>>> On Tue, Oct 21, 2025 at 1:58 AM Adhemerval Zanella Netto
> >>>>> <adhemerval.zanella@linaro.org> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 18/10/25 03:28, H.J. Lu wrote:
> >>>>>>> On Sat, Oct 18, 2025 at 3:58 AM Adhemerval Zanella
> >>>>>>> <adhemerval.zanella@linaro.org> wrote:
> >>>>>>>>
> >>>>>>>> We need to disable the internal optimize for math builtins
> >>>>>>>> (NO_MATH_REDIRECT) for the USE_TRUNC_BUILTIN case.
> >>>>>>>
> >>>>>>> Does it change GCC codegen?
> >>>>>>
> >>>>>> No, both with clang and gcc either the builtin is issues (on
> >>>>>> aarch64 for instance) or the internal symbol is called.
> >>>>>
> >>>>> Why does NO_MATH_REDIRECT make no difference here?
> >>>>> Why is this macro needed?
> >>>>
> >>>> With clang the internal optimization to avoid PLT usage for symbol
> >>>> that might be inline will make clang to *not* emit the builtin:
> >>>>
> >>>> include/math.h
> >>>>
> >>>> 177 MATH_REDIRECT (trunc, "__", MATH_REDIRECT_UNARY_ARGS)
> >>>>
> >>>> Without NO_MATH_REDIRECT, which disables it; build with clang
> >>>> fails:
> >>>>
> >>>>>>> referenced by s_modf.c:34 ([...]/../sysdeps/ieee754/dbl-64/s_modf.c:34)
> >>>>>>>               [...]/aarch64-linux-gnu-clang-21/libc_pic.os.clean:(__modf)
> >>>> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> >>>>
> >>>> gcc is not affected by this, it will emit the 'frintz' regardless
> >>>> of MATH_REDIRECT.
> >>>
> >>> So clang won't inline trunc without NO_MATH_REDIRECT?
> >>> Why isn't gcc impacted?
> >>>
> >>
> >> Here is a simplified testcase:
> >>
> >>   extern float truncf (float __x) __attribute__ ((__nothrow__ )) __attribute__ ((__const__));
> >>   extern float __truncf (float __x) __attribute__ ((__nothrow__ )) __attribute__ ((__const__));
> >>
> >>   #ifdef ALIAS
> >>   float (truncf) (float) asm ("__truncf");
> >>   #endif
> >>
> >>   float foo (float x) { return truncf (x); }
> >>
> >> If ALIAS is defined clang will always emit a __truncf call. It seems that alias
> >> are applied as early as possible, from -emit-llvm -mllvm -print-after-all
> >> I see that ForceFunctionAttrsPass is the first used and it already issues
> >> a "%call = call float @__truncf(float noundef %0) #2".
> >>
> >
> > GCC does the same:
> >
> > [hjl@gnu-tgl-3 tmp]$ gcc -S -O2 t.c
> > [hjl@gnu-tgl-3 tmp]$ cat t.s
> > .file "t.c"
> > .text
> > .p2align 4
> > .globl foo
> > .type foo, @function
> > foo:
> > .LFB0:
> > .cfi_startproc
> > jmp truncf
> > .cfi_endproc
> > .LFE0:
> > .size foo, .-foo
> > .ident "GCC: (GNU) 15.2.1 20250924 (Red Hat 15.2.1-2)"
> > .section .note.GNU-stack,"",@progbits
> > [hjl@gnu-tgl-3 tmp]$ gcc -S -O2 t.c -DALIAS
> > [hjl@gnu-tgl-3 tmp]$ cat t.s
> > .file "t.c"
> > .text
> > .p2align 4
> > .globl foo
> > .type foo, @function
> > foo:
> > .LFB0:
> > .cfi_startproc
> > jmp __truncf
> > .cfi_endproc
> > .LFE0:
> > .size foo, .-foo
> > .ident "GCC: (GNU) 15.2.1 20250924 (Red Hat 15.2.1-2)"
> > .section .note.GNU-stack,"",@progbits
> > [hjl@gnu-tgl-3 tmp]$
> >
> > What is the real issue?
> >
>
> That is not what I am seeing https://godbolt.org/z/7YT5Y5PPr . I am not sure
> why it not triggering in your end.

truncf is always inlined with SSE4 and GCC 16, with and without
asm ("__truncf").   But clang doesn't inline it with asm ("__truncf").
Do we want to inline truncf or not?

-- 
H.J.