Re: Please revert b2e843161d

On 6/25/26 01:15, Andrew Turner wrote:
> 
>> On 24 Jun 2026, at 19:58, Steve Kargl <kargls@comcast.net> wrote:
>>
>> Can someone with commit access please revert b2e843161dc3b?
>>
>>    git log -r b2e843161dc3b79777e873183447c92ed9c3703a
>>    Author: Andrew Turner <andrew@FreeBSD.org>
>>    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

and the base system compiler

% cc --version
FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git 
llvmorg-19.1.7-0-gcd708029e0b2)
Target: x86_64-unknown-freebsd16.0
Thread model: posix
InstalledDir: /usr/bin

If one has a libm that was compiled with any of the USE_BUILTIN
macros, it is not possible to debug a program that uses those
functions if the -fno-builtin option is in play.  A closer
look shows that fmaf() is simply broken if USE_BUILTIN_FMAF is
used.

At least on x86_64, one can force the use of a builtin function
with compiler options.  With libm builtin without USE_BUILTIN_FMAF

% cc -O3 -o z t5.c -lm && ./z
-0x1.f22d44p-3              <-------- Note bug in software fmaf
% nm z | grep fmaf          <-------- Reference to library function
                  U fmaf

% cc -O3 -o z t5.c -mfma -lm && ./z
-0x1.f22d46p-3              <-------- Uses clang builtin, correct output
% nm z | grep fmaf          <-------- There is no function call.

% cc -O3 -o z t5.c -mfma -fno-builtin -lm && ./z
-0x1.f22d44p-3              <-------- Note bug in software fmaf
% nm z | grep fmaf          <-------- Reference to library function
                  U fmaf

Now, using my private copy of libm where I do all my hacking to
keep the system's libm pure.  I only build libm.a, which is named
libmath.a.

% cc -O3 -o z t5.c -L ~/trunk/math/libm/msun -lmath && ./z
-0x1.f22d46p-3             <---- Correct value because I fixed the bug
% nm z | grep fmaf
0000000000201720 T fmaf

Now rebuild libmath.a with -DUSE_BUILTIN_FMAF

% cc -O3 -o z t5.c -L ~/trunk/math/libm/msun -lmath && ./z
Segmentation fault (core dumped)
% nm z | grep fmaf
0000000000201680 T fmaf
% cc -O3 -o z t5.c -mfma -L ~/trunk/math/libm/msun -lmath && ./z
-0x1.f22d46p-3          <-------- Uses clang builtin, correct output
% nm z | grep fmaf      <-------- There is no function call.
% cc -O3 -o z t5.c -march=native -L ~/trunk/math/libm/msun -lmath && ./z
-0x1.f22d46p-3          <-------- Uses clang builtin, correct output
hotrats:kargl[448] nm z | grep fmaf

So, to actually use the builtin one needs to use the -mfma
option anyway; or, tune for the CPU via -march=native.

Let's look at the core,

% cc -O -g -o z t5.c -L ~/trunk/math/libm/msun -lmath && ./z
Segmentation fault (core dumped)
% gdb151 ./z
(gdb) run
Starting program: /home/kargl/tmp/z

Program received signal SIGSEGV, Segmentation fault.
Invalid permissions for mapped object.
0x0000000000201684 in fmaf ()

-- 
steve