Once in a blue moon or two we stumble upon compiler bugs and after carefully ruling out that it’s our error (or maybe just differences between compilers) we confirm we really have one.
One of our tests started failing when we bumped to the HEAD of the develop branch of JUCE and updated to Xcode 14.3
After a lot of debugging I narrowed it down to a difference in result when calling
Line<float>::findIntersection with certain inputs.
With even more debugging and messing around with the code I determined that this line was resulting in different results for some inputs than it used (the tests continue to pass on Windows with latest MSVC, btw).
I didn’t examine the produced assembler code (I don’t know any ARM) but I did find that if I split up the calculation then the old behaviour returned (an old trick I’ve used to work around compiler bugs before):
This now produces the old expected results:
const auto s1 = p1.y - p3.y; const auto s2 = p1.x - p3.x; const auto m1 = s1 * d2.x; const auto m2 = s2 * d2.y; const auto s3 = m1 - m2; const auto along1 = s3 / divisor;
It would be extremely helpful for us if you would be willing add this work-around for the Xcode (clang?) bug*.
The results would be the same as they used to and it would not hurt anyone. We could even put some compile time checks against the version of the compiler if you would like to check if it’s fixed one day in the future? On request I can supply exact versions of the inputs that demonstrate the issue. Weirdly, it doesn’t happen if I isolate that calculation outside of this function, which strengthens the case that it’s a compiler bug.
- It might not technically be a bug but some corner of the spec that allows for this difference. I’m no expert on such deep parts of the C++/ieee 754/ARM64 specs.