Add comments.

Address comments.

Add comments explaining the correction part.

Fix comment typo.

Remove unused local variables.

[trivial] Fix test comment.

Change UInt_t to UIntType.

Update constants for FDimTest.

[libc] Add implementations of fdim[f|l].

[libc] Add implementations of fdim[f|l].

Change to snake_case.

Change to early return pattern.

Remove TODO's.

Fix comments alignment and remove commented tests.

Update to the new floating point testing facility.

Update comments.

Update comments

Correct the eps when the input is a power of 2, and add a check for correct rounding to even when it is a tie.

Merge with reviews.llvm.org/D85486

In D84725#2183801, @sivachandra wrote:

We currently have UnitTest depend on FPUtil. I think that an creates unnecessary dependency for tests which do not need FPUtil for testing. So, a plan could be:

Instead of EXPECT_EQ and friends for floating point numbers, we will decouple UnitTest from FPUtil using matchers implemented in FPUtil. Say, EXPECT_FP_MATCH etc.

WDYT? If you concur, then you need not do the work. I will do it, and you can absorb those changes into this patch.

Fix explicit specialization in class scope.

[libc] Add implementations of fmax, fmaxf, and fmaxl.

Update Test (EXPECT_EQ and friends) to accept __uint128_t and floating point types (float, double, long double).

In D83931#2156530, @sivachandra wrote:

In D83931#2155091, @abrachet wrote:

Why add support to the TEST macros for this when we have the MPFR macros which I think handle floats better than we can with TEST. Comparisons with floating points are not fun, its why we use the mpfr library in the first place. Is there even a need to use the TEST macros with floats?

Let me give some explanation from my side for this. For non-trivial math functions like trignometric functions, comparing with MPFR result makes sense because we can use MPFR as source of truth/correctness. But, for functions like fmin and friends, comparing with MPFR is an overkill. I agree that comparing floating points in general could be problematic and that is the reason why we did not allow floating comparisons until now. But, if we restrict ourselves to values which have an exact bit representation, then comparisons are precise and deterministic. For example, zero, infinity and small decimals like 10.0, 1.2345 etc. have exact bit representation in all relevant floating point formats Likewise, if a floating point number is actually constructed from the bit representation, then that number has exact bit representation by construction. So, comparing such numbers would be precise.

One can ask, how can we ensure one uses only exact floating point numbers in tests. I don't have a good answer other than saying "code review". May be we can write a clang-tidy driven tool in future. Irrespective, I think this patch improves the readability of the tests. @lntue is the expert here so he might have more to add.

Update Test (EXPECT_EQ and friends) to accept __uint128_t and floating point types (float, double, long double).

Update Test (EXPECT_EQ and friends) to accept __uint128_t and floating point types (float, double, long double).

Add implementations of fmin, fminf, and fminl. Testing infrastructure update is splitted to https://reviews.llvm.org/D83931.

Refactor utohexstr and overloads of raw_stream.operator<<