Fix overflow in pow5

[LilithHafner]

Fixup for #46764. See the post-merge conversation for context. Reposting the comment that motivates this pr:

julia> using Printf

julia> @printf "%.8g" 4.645833859177319e63 # master
4.6458338e+63

julia> @printf "%.8g" 4.645833859177319e63 # 1.8
4.6458339e+63

There are two ways that pow5 can be wrong,

1. returning false when m2 is divisible by big(5)^requiredFives
2. returning true when m2 is not divisible by big(5)^requiredFives
   In the first case, for pow5 to be wrong, big(5)^requiredFives must be greater than typemax(Int), but m2 is always less than 1<<53, and a small number is not divisible by a large number. Thus m2 will never be divisible by the true big(5)^requiredFives when there is overflow and case 1 is okay.

For the second case, we need to find a requiredFives such that pow5 may wrongly return true. That is, find a requiredFives such that there exists m2 where m2 % 5^requiredFives == 0 For this to be the case, either m2 must be 0 (handled much earlier as a special case) or abs(5^requiredFives) <= m2 < 1<<53. Searching exhaustively from the cases that have overflow, findfirst(requiredFives -> abs(5^requiredFives) < 1<<53, 28:10^5)+27 == 55. Note that 5^55 < 0. If, on the other hand, we used unsinged(5)^requiredFives, then we'd have findfirst(requiredFives -> unsigned(5)^requiredFives < 1<<53, 28:10^5)+27 == 1048 and IIUC requiredFives is at most log10(floatmax(Float64)) == 308.25471555991675.

So using unsigned(5) should fix this and I benchmark it as comparable to signed exponentiation.

[martinholters]

Too lazy to try and follow that reasoning, but does that also work if unsinged(5) isa UInt32?

[LilithHafner]

Good catch! No, the story is much worse then because the x can still be up to almost 1<<53 and 5^p is bounded by typemax(UInt32) so false positives are much easier to construct. Easy fix though.

[StefanKarpinski]

Brava, @LilithHafner 👏🏻

[LilithHafner]

Unless folks object, I'm going to merge this. The reasoning justifying that the new behavior is always correct is complex, but it is pretty clear that this is at least an improvement.

[oscardssmith]

go for it.