NB: glm::detail::tmat2x2::_inverse() incorrectly swaps all components instead of only main diagonals:
A = ⌈a b⌉
⌊c d⌋
(using standard representation). _inverse() on A incorrectly gives the order
⌈ d -c⌉
⌊-b a⌋
(swaps both diagonals) where it should be
⌈ d -b⌉
⌊-c a⌋
(I am leaving out division by the determinate for clarity).
Also, glm::inverse() in `glm/core/func_matrix.inl` is correct for 2x2 matrices and shows the mistake of _inverse().
The unit tests do not appear to test division of a mat2 by a mat2 (where this could arise).
The previous fix only worked correctly for values where
the most significant enabled bit was the only enabled bit.
This change changes the implementation back to using clz,
but so that the result is changed with additional arithmetics.
There is still at least one known limitation with regards
to acceptable input types, but this is documented in the code.
Before this fix, the GCC specific MSB function returned the number
of leading zero bits in the parameter value. With this change,
the number of trailing zero bits is returned instead.
I am not entirely sure if this fix is correct, because I could not
find a clear reference about what findMSB in GLSL is really
supposed to return with some concrete input value.
At least the result is now consistent with the GLM_ARCH_PURE
implementation of glm::findMSB.
This pretty much reverts the fix done in commit
1ed0e3865b5de0ee993b064b37749bc85e928d7f
This temporarily breaks log2 for GCC in cases where GLM_FORCE_PURE
is not defined. The workaround introduced in commit
1ed0e3865b5de0ee993b064b37749bc85e928d7f seems to rely
on getting invalid results from the nlz function.
Broken nlz is caused by a broken findMSB function for GCC.
A fix for the findMSB function should be available in a nearby
separate commit.
