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

[Adhemerval Zanella Netto]

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.