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

[H.J. Lu]

On Fri, Oct 24, 2025 at 6:28 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> 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?
>

I opened:

https://sourceware.org/bugzilla/show_bug.cgi?id=33576

-- 
H.J.