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

[H.J. Lu]

On Fri, Oct 24, 2025 at 6:19 AM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 23/10/25 19:06, H.J. Lu wrote:
> > 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?
>
> Yes, that why the architecture defines USE_TRUNCF_BUILTIN and why I had
> to add NO_MATH_REDIRECT. Otherwise clang will emit a libcall and since
> libc.so does not have the trunc object the link fails.

Can we not define alias when USE_TRUNCF_BUILTIN is defined?


--
H.J.