[Bug 294719] lib/msun: Added fmaximum_mag_num
[email protected] Tue, 28 Apr 2026 20:40:55 +0000
| Newsgroups | gmane.os.freebsd.devel.standards |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D294719 --- Comment #9 from Robert Clausecker <[email protected]> --- (In reply to Steve Kargl from comment #8) The problem is that our signbit() macro resolves to a __signbit() function, which gcc and clang do not recognise as being the signbit() macro. This is probably fixable by checking if the compiler has a built-in implementation = and then resolving signbit() to __builtin_signbit(), but let's do that another time. > I haven't figured out what Jesus is trying to do > with the force_except. Reading the description of > fmaximum_num etc, I would try something like The idea is that we force the compiler to perform an addition on the NaN values. If either is a signalling NaN, this raises FE_INVALID as usual, avoiding a costly branch and sign-bit check. We do similar things in other variants of the fmax/fmin family. Whenever return (x + y) is used to return a NaN, that too raises FE_INVALID if eithe= r is a signalling NaN. > Need to some bit twiddling to do the equivalent. I've checked the assembly of a the functions and the bitfield-union approac= h we use is surprisingly inefficient. It's probably a good idea to try to avoid doing this sort of stuff if we can help it. --=20 You are receiving this mail because: You are the assignee for the bug.=