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

[H.J. Lu]

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?

-- 
H.J.