Re: Please revert b2e843161d

On 6/25/26 10:57, Andrew Turner wrote:
> 
> 
>> On 25 Jun 2026, at 17:42, Steve Kargl <[email protected]> wrote:
>>
>> On 6/25/26 01:15, Andrew Turner wrote:
>>>> On 24 Jun 2026, at 19:58, Steve Kargl <[email protected]> wrote:
>>>>
>>>> Can someone with commit access please revert b2e843161dc3b?
>>>>
>>>>   git log -r b2e843161dc3b79777e873183447c92ed9c3703a
>>>>   Author: Andrew Turner <[email protected]>
>>>>   Date:   Tue Nov 2 11:31:17 2021 +0000
>>>>
>>>>   Use a builtin where possible in msun
>>>>
>>>>
>>>> If one has a libm built with, e.g., -DUSE_BUILTIN_FMAF,
>>>> and then tries to debug code that uses fmaf() where the
>>>> compiler options include -fno-builtin, a segfault
>>>> occurs.  I suggest purging all of the recent additions
>>>> of USE_BUILTIN_*.  These are simply not needed as a compiler
>>>> will use a builtin (if available) instead of a function from
>>>> libm.
>>> What architecture and compiler are you using to build libm?
>>> I only enabled it on arm64 as both llvm and gcc will generate the 
>>> optimal assembly instruction. Other architectures and compilers the 
>>> builtin may generate a call to fmaf creating an infinite loop.
>>
>> I'm using
>>
>> % uname -a
>> FreeBSD hotrats 16.0-CURRENT FreeBSD 16.0-CURRENT #0 main-n284956- 
>> de9fe28ab847: Fri Apr 10 10:15:09 PDT 2026 kargl@hotrats:/usr/obj/usr/ 
>> src/amd64.amd64/sys/GENERIC amd64
> 
> I don’t expect it to work on amd64 in the general case. Godbolt shows 
> both GCC and Clang generating an infinite loop jumping to its self [1]. 
> It may work on some architecture levels, however I don’t know enough 
> about amd64 to know if it’s safe to enable.

Just checked godbolt.  If one uses -O3 -fno-builtin with either gcc
or clang, the generate assembly includes a call to fmaf in libm.a.
If you build libm with -DUSE_BUILTIN_FMAF on arm and you use
-fno-builtin, does the resulting executable seg fault?

-- 
steve