Model bugs with latest GCC 14 and Clang 19 #1312
Comments
|
An easy way to test both GCC 14 and Clang 19 is to use Ubuntu Noble (it has GCC 14 in repositories) and to install Clang 19 from the LLVM upstream repository for Ubuntu: https://apt.llvm.org |
|
As usual this doesn't happen with GCC 14.2 on Windows. Does it matter what |
|
I get the same results with both DLL and EXE cgame. I get the same results with |
|
Interesting, with NEXE cgame, I reproduce the Clang 19 bug, but not the GCC 14 bug. |
|
Removing |
|
Engine build with GCC13 (unaffected) with game built with current Saigo (based on Clang 19, affected):
So that looks to be a game code bug. |
|
The bug affects both the engine and the cgame, but it looks different if both engine and games are compiled with affected compilers than only one of them.
The weirdness seen with non-fast-math Clang 19 engine with fast-math Saigo is the same as fast-math GCC 13 engine with fast-math Saigo. |
|
I have no idea what is causing this, I was hoping to catch some division by zero. I have noticed that using a debug build workarounds the bug too, even when enabling fast math. |
|
I wonder if some underflow I catch on model loading is related or not: |
|
According to https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html the
So with GCC 14 (known to reproduce the bug) I replaced But, I could also enable either one of |
|
That GCC documentation page also says that
But when I replace |
|
Interestingly, using |
|
It looks like what makes the difference is to use |
|
But using It should be noted that using So the flag combination is not totally reversible, but the bug has strong chance to be related to using |
|
Hmm, good to know, using So, that may still be some division by zero or things like that, the problem is that we cannot catch it with
|
|
But when I use |
|
Also using |
|
It works without bug on CLANG 19 with It's likely not a division by zero because |
|
|
|
Disabling custom SSE code workarounds the bug. |
|
Nice find! We should also see if -ffast-math actually makes a noticeable difference in performance. |
|
A quick gut check for plat23 as spec in A base ( Based on this single datapoint, it might not even be worth the hassle. |
|
TransAddRotationQuat doesn't seem to work correctly with Clang 19. I have a failing unit test: static void ExpectTransformEqual(const transform_t &t1, const transform_t &t2)
{
for (int i = 0; i < 8; i++)
{
float n1, n2;
memcpy(&n1, reinterpret_cast<const char*>(&t1) + 4 * i, 4);
memcpy(&n2, reinterpret_cast<const char*>(&t2) + 4 * i, 4);
EXPECT_FLOAT_EQ(n1, n2) << "transform_t's unequal at offset " << 4 * i;
}
}
TEST(QMathTest, TransAddRotationQuat)
{
transform_t t1, t2;
TransInit(&t1);
TransInit(&t2);
quat_t q;
QuatFromAngles(q, 33, 59, 124);
TransAddRotationQuat(q, &t1);
TransInsRotationQuat(q, &t2);
ExpectTransformEqual(t1, t2);
}This unit test might not even be correct if there is more than 1 way to represent a quat or something, but it passes with another compiler. |
|
I added |
|
The problem with Clang is that it now can't correctly handle SSE bit mask intrinsics on floating point vectors when We can work around this by using shuffle intrinsics instead of bit masks. These are presumably faster anyway: if you put the code with masks into (a non-bugged configuration of) Clang, it transforms them into shuffles. |
Fixes the Clang part of DaemonEngine#1312. The problem is that LLVM wrongly considers __m128 to have floating-point semantics at all times. When it sees an all-ones mask in some component it wrongly sees it as a NaN and replaces it with an undefined value when in -ffinite-math mode. In the cases where the new first_XYZ_second_W is used, that is actually what Clang itself outputs after optimizing the original intrinsics code (with a non-bugged flag configuration). So hopefully it is faster anyway.
|
Disabling SSE doesn't fix the GCC 14 bug, so that's a different bug than the Clang one. |
Fixes the Clang part of #1312. The problem is that LLVM wrongly considers __m128 to have floating-point semantics at all times. When it sees an all-ones mask in some component it wrongly sees it as a NaN and replaces it with an undefined value when in -ffinite-math mode. In the cases where the new first_XYZ_second_W is used, that is actually what Clang itself outputs after optimizing the original intrinsics code (with a non-bugged flag configuration). So hopefully it is faster anyway.
|
I wonder what is that remaining GCC bug. I noticed the distortion is affected by the orientation of the model on vertical axis. With some angles there is no distortion, with some there is a few, with some others there is much. |
|
This can be seen while playing with a dretch and |
|
I now have a branch with I now suspect a compiler bug in some optimization. |
|
So, as a summary, the
|
I remember @DolceTriade said one day he seen bugs while compiling with GCC 14.
I confirm I see bugs affecting models in a weird way when compiling with GCC 14 (no issue with GCC 13):
First stable version of Clang 19 was released today and then out of curiosity I test it, and I got another bug but affecting the models too, but in a different way (no issue with Clang 18):
Maybe we actually do something wrong if two compilers fail on it.
The text was updated successfully, but these errors were encountered: