GCC 5.0 Doesn't Show Much Difference Yet For AMD's Steamroller

[AnAkIn]

I've been trying to compile one of my projects with gcc 4.9.1 in Arch, every time it produced wrong assembly which lead to the program crashing. Switched to clang, now everything works fine.

[carewolf]

I've been trying to compile one of my projects with gcc 4.9.1 in Arch, every time it produced wrong assembly which lead to the program crashing. Switched to clang, now everything works fine.

If you program contains invalid code that can cause GCC to miscompile it is only a matter of time before issues will crop up with any compiler. Better fix your code than complain about compilers.

Rule of thumb: If you think you have spotted a compiler error. You should consider youself wrong and fix your code instead (With more than 10 years of experience with C++ I have found one compiler error in GCC, but suspected errors more than 10 times and been wrong in every case but once).

[JS987]

I've been trying to compile one of my projects with gcc 4.9.1 in Arch, every time it produced wrong assembly which lead to the program crashing. Switched to clang, now everything works fine.

gcc often generates wrong code and it can take long time to fix. You should report bug to https://gcc.gnu.org/bugzilla/

[AnAkIn]

If you program contains invalid code that can cause GCC to miscompile it is only a matter of time before issues will crop up with any compiler. Better fix your code than complain about compilers.

Rule of thumb: If you think you have spotted a compiler error. You should consider youself wrong and fix your code instead (With more than 10 years of experience with C++ I have found one compiler error in GCC, but suspected errors more than 10 times and been wrong in every case but once).

The code is in Valve's Source SDK, which I need for my project, and there's nothing wrong with it, it's a pretty simple code. MSVC and Clang compiles it correctly. GCC used to compiles it correctly as well, just not the latest versions.

[Zan Lynx]

The code is in Valve's Source SDK, which I need for my project, and there's nothing wrong with it, it's a pretty simple code. MSVC and Clang compiles it correctly. GCC used to compiles it correctly as well, just not the latest versions.

It is entirely possible for widely used library code to have subtle bugs. Popular ones are aliasing bugs. Whenever there is a pointer cast, view it with the utmost suspicion. Sometimes library functions are misused, like using memcpy or strcpy that only sometimes overlaps. Or a local variable's address might be returned and used in its caller, which may work fine until a compiler decides to inline and reorder the entire function chain. Or in C++ code an exception might be thrown with a local pointer. That is never a good idea but it sometimes appears to work.

Things like that are why I always run my test sets against both the debug code with asserts and also the O3 profile optimized version.

To sum up: Just because some code has been used for a long time, and other compilers compile it correctly, does NOT mean that the code is correct.