Today, I encountered an interesting side effect. An executable file compiled on an AMD-based computer using ReleaseSmall with LLVM did not work on an Intel-based computer. It crashed with a trap invalid opcode error. Both computers had the same version of Linux.
After recompiling using ReleaseSafe, the issue seemed to have resolved. I wonder what caused this problem. Has anyone else encountered similar issues?
What was your target, when you compiled the binary? By default the target is the machine, which you use to compile. This means, that your exe is allowed to uses instructions which are specific to the family of AMD processors, which you use.
Yes, target was native by default. But it was the same when I used ReleaseSafe.
I assume that in ReleaseSmall, the compiler uses some deeper optimizations and may use specific target processor instructions.
ReleaseSafe and ReleaseSmall differ in what optimizations they use, but the cause could also be, that the safety checks in ReleaseSafe make optimizations or the use of specific instructions impossible or that code in the exe depends on @import("builtin").mode in some way which results in different machine code.
No, builtin is not used in this code at all. Studying similar cases with other products, in particular with Postress, revealed that the problem is confirmed in the Linux kernel from 5.18 to 6.8 inclusive. In 6.9, the problem has already been fixed. Moreover, it does not reproduce every time and requires several factors to come together. Therefore, Zig and optimization are not involved in this issue.
It does not need to be used in the code that you write. E.g. ReleaseSmall uses a different memcpy function, which is used when @memcpy() or the c memcpy() function is used, or when you copy a big variable, but as you mentioned: Since there are other required factors, this is likely irrelevant.