I had a chance to investigate the "test_fabs" failure test_fabs checks for correctness for a number of math related functions. Of the ones tested "ilogb" and "ldexp" fail on arm64.
ilogb ------ ilogb(x) returns FP_ILOGB0 when x = 0, and FP_ILOGBNAN when x = NaN; According to OpenCL 1.2, the valid values for FP_ILOGB0 are either INT_MIN or -INT_MAX (note the '-' sign). Similarly the valid value for FP_ILOGBNAN are either INT_MIN or INT_MAX. ISO C has a similar specification of ilogb() so nothing unusual about it. Looking at glibc, it looks like the choice of value for FP_ILOGB0 and FP_ILOGBNAN is architecture dependent, e.g., FP_ILOGB0 is "INT_MIN" on x86 but "-INT_MAX" on arm64. The check in "test_fabs" fails because the value returned by the underlying implementation of ilogb() doesn't match on "0" and "NAN". The implementation of ilogb(0) returns "-INT_MAX" while FP_ILOGB0 is defined as "INT_MIN" in pocl. Similarly, ilogb(NaN) returns "INT_MAX" while FP_ILOGBNAN is defined as "INT_MIN" in pocl. I couldn't find any definition of FP_ILOGB* macro in sleef (which seems to be the vector library used by pocl) so it seems to be picking up that value from system defines or compiler builtins. One way to fix it would be for pocl to match definitions of FP_ILOGB* but don't know if that is the right way to fix this problem. Andreas, do you know what should be done here?
