I just emerged gcc-4.0.3 on a Pentium Mobile. I have a program that behaves as expected when compiled with -O0 but gives different output when compiled with -O3. I do not know what to do about it. The program is called prov. Here is the result of compiling and running it: $ g++-4.0.3 -O0 -Wall -o prov prov.cc -I/usr/include/SDL && ./prov; echo $? 1 $ g++-4.0.3 -O3 -Wall -o prov prov.cc -I/usr/include/SDL && ./prov; echo $? 0 The program looks like this: ______________________________________________________ #include <SDL_types.h> struct Coords { bool operator<(const Coords other) const { return *reinterpret_cast<const Uint32 * const>(this) < *reinterpret_cast<const Uint32 * const>(&other); } int x : 16, y : 16; }; int main() { Coords a = {0, 1}, b = {1, 0}; return b < a and a < b; } ______________________________________________________ The operator< is for use with standard containers, so it has to work. It should of course never happen that b is less than a and a is less than b, so the program should always return 0. I can see that the assembly output is very different, but I admit that I do not understand much of it. With g++-3.4.5 the program produces identical and correct output for the different optimization levels.
seems to be gcc-4.0 only issue ... 3.4.6 and 4.1.0 work fine for me
As gcc 4.1 points out with -Wall, this code isn't valid since you can't just cast pointers to different types and then try to read values as something they're not. There are exceptions, but this isn't one of them. You may be able to use the -fno-strict-aliasing option to get away with it though, but even then, it would be a good idea to rewrite the code, for example by using memcmp(). I'm pretty sure that only if it still doesn't work with that option, this can be considered a bug in GCC.
I would rewrite the code if I found a good alternative. Correct me if I am wrong, but memcpy is a function call, which requires several more instructions. This code is a performance bottleneck and must be as fast as possible. What I have is a 32-bit type (Coords) consisting of 2 16-bit variables (x and y). The fastest ordering functor I can think of for that situation is to just treat the 2 16-bit variables as a 32-bit variable and compare that. If I understand correctly that is just a single instruction. That sounds simple, doesn't it? The code you see is the only way I could find to do that. Anyone is welcome to suggest a better way.
You didn't mention whether -fno-strict-aliasing works for you.
-fno-strict-aliasing seems to work. At least for that particular testcase. The program returns 0 for both -O0 and -O3.
In that case, I think gcc is behaving properly here. With -fstrict-aliasing, you're telling gcc you don't do weird pointer stuff like that, and as that's not allowed in standard C (or C++) either, it's enabled automatically at -O2+.
sounds good
