> Date: Fri, 30 Oct 2020 08:34:46 -0700 (PDT) > From: [email protected] > > >Synopsis: arm64 ilogbf(0.0) incorrect result, should be INT_MIN > >Category: system > >Environment: > System : OpenBSD 6.8 > Details : OpenBSD 6.8-current (GENERIC.MP) #871: Wed Oct 28 > 10:16:14 MDT 2020 > > [email protected]:/usr/src/sys/arch/arm64/compile/GENERIC.MP > > Architecture: OpenBSD.arm64 > Machine : arm64 > >Description: > Sample program shows INT_MIN = -2147483648, ilogbf(0.0) is defined > by the manpage as INT_MIN but comes out off-by-one, -2147483647. > Same incorrect result from ilogb(0.0) as well. > > Note that amd64 is correct, so this is arch-specific. > >How-To-Repeat: > The following code shows the result: > > #include <stdio.h> > #include <math.h> // ilogbf, pow > int > main() { > printf(" ilogbf (%g) is %d, INT_MIN is %d\n", > 0.0, ilogbf(0.0), INT_MIN); > printf(" ilogb (%g) is %d, INT_MIN is %d\n", > 0.0, ilogb(0.0), INT_MIN); > } > > >Fix: > Some kind of correction to ilogb(3), ilogbf(3) >
It's a bit more complicated that that. ISO C actually says that ilogb(0) should return FP_ILOGB0, which shall either be INT_MIN or -(INT_MAX). Our <math.h> defines FP_ILOGB0 as: #define FP_ILOGB0 (-INT_MAX) So in that respect the arm64 implementation is correct and this is a documentation bug. That said, the amd64 and i386 implementations use hardware instructions that use the FP_ILOGB0 == INT_MIN convention. So we either have the make FP_ILOGB0 machine dependent, or change some of the implementations.
