GCD bug fix

The standard-library documentation for `trailingZeroBitCount` states:

> If the value is zero, then `trailingZeroBitCount` is equal to `bitWidth`.

Thus, if `T` is not a fixed-width integer type, and `x == 0`, and `y` has more trailing zeros than the representation of `x`, then the gcd calculation will be incorrect.

In particular, the left-shift by `min(xtz, ytz) == xtz` will not “undo” the earlier right-shift by `ytz`,  so the final result will be incorrectly right-shifted by `ytz - xtz`.

To fix this I have added an early exit when `x == 0`. I am not sure if this is the optimal solution, and I’m open to alternatives.

***

This change ensures that `x != 0` at the top of the loop, so I have also converted it from a `while` to a `repeat-while` loop, in order to eliminate a redundant extra comparison on the first iteration.

I don’t know if this actually affects performance, and I’m happy to change it back if that’s preferred.

Author: NevinBR

Sources/IntegerUtilities/GCD.swift

@@ -27,6 +27,7 @@ public func gcd<T: BinaryInteger>(_ a: T, _ b: T) -> T {
   var x = a.magnitude
   var y = b.magnitude
 
+  if x == 0 { return T(y) }
   if y == 0 { return T(x) }
 
   let xtz = x.trailingZeroBitCount
@@ -39,11 +40,14 @@ public func gcd<T: BinaryInteger>(_ a: T, _ b: T) -> T {
   // After the right-shift in the loop, both x and y are odd. Each pass removes
   // at least one low-order bit from the larger of the two, so the number of
   // iterations is bounded by the sum of the bit-widths of the inputs.
-  while x != 0 {
+  //
+  // A tighter bound is the maximum bit-width of the inputs, which is achieved
+  // by odd numbers that sum to a power of 2, though the proof is more involved.
+  repeat {
     x >>= x.trailingZeroBitCount
     if x < y { swap(&x, &y) }
     x -= y
-  }
+  } while x != 0
 
   return T(y << min(xtz, ytz))
 }