RFR: 8325438: Add exhaustive tests for Math.round intrinsics [v8]

[Emanuel Peter]

On Tue, 19 Mar 2024 15:04:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> HI,
>> Can you have a look at this patch adding some tests for Math.round instrinsics?
>> Thanks!
>> 
>> ### FYI:
>> During the development of RoundVF/RoundF, we faced the issues which were only spotted by running test exhaustively against 32/64 bits range of int/long.
>> It's helpful to add these exhaustive tests in jdk for future possible usage, rather than build it everytime when needed.
>> Of course, we need to put it in `manual` mode, so it's not run when `-automatic` jtreg option is specified which I guess is the mode CI used, please correct me if I'm assume incorrectly.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename

> For inf, the probability is 2 in all runs (+inf, -inf); for NaN, the probability is (eStep/eBound) (but depends on rand value), in new version I modify it to make sure it tests NaN, so it's (eStep/eBound) now.
> Just my experience, for Math.round(float/double), special cases like inf/NaN are not the error-prone ones, normal values are more error-prone.

Maybe it is not super error-prone, but you never know. I've seen multiple bugs with other float-operations, so now it always makes me nervous when I don't see them.

Can you please throw in these special cases explicitly, so we can be sure we have them?
I think that the significand/exponent combination works now, but I'm always a bit scared that we still have an error, and we don't see it. That is why I think it would be nice to have at least one very clean random number that is thrown it as well, that has no modifications to it.

But your generation method clearly has advantages: we systematically cover all ranges. That is good.

Thanks for the work :)

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17753#pullrequestreview-1948822091