The -O2 optimization breaks C++ code on some machines - linux

Question

I have 3 different machines with the following configurations:
OpenSuSe 12.1, linux kernel 3.1.10, gcc 4.6.2
Debian 6, linux kernel 2.6.32, gcc 4.4.5
CentOS 5.6, linux kernel 2.6.18, gcc 4.1.2
All their architectures are x86_64. Note that CentOS' software versions are older than Debian's, but versions of OpenSuSe software are newer than Debian's versions.
And I have the following example code:
#include <cstdio>
#include <cstdlib>
unsigned int cols=5;
unsigned int rows=6;
int main()
{
//allocating...
double **mat=new double*[rows];
double *col=new double[rows];
for(unsigned int i=0;i<rows;++i)
{
mat[i]=new double[cols];
}
//filling with something...
for(unsigned int i=0;i<rows;++i)
{
for(unsigned int j=0;j<cols;++j)
{
mat[i][j]=i+j;
}
}
//testing...
unsigned long long sum,add;
for(unsigned int i=0;i<cols;++i)
{
sum=0;
for(unsigned int j=0;j<rows;++j)
{
col[j]=mat[j][i];
add=*((unsigned long long*) (&(col[j])));
sum+=add;
}
printf("%llu\n",sum);
}
return 0;
}
If I compile this code without any options:
g++ code.cpp
it runs in the same way on all machines.
But if I compile it with -O2, it behaves in the same way on the 1st and the 3rd machines, but on the 2nd machine (Debian) the -O2 optimization breaks it.
This is the output of this code on the 1st machine with -O2:
4619567317775286272
9238008735643729920
9250393634618998784
9259400833873739776
9266719183268216832
And this is on the 2nd machine with -O2:
0
4619567317775286272
9238008735643729920
9250393634618998784
9259400833873739776
The output of the second machine looks like the 1st' output, shifted down by one line.
If I replace (&(col[j])) with (&(mat[j][i])), the code begins to work normaly.
Here is the compiler's output on the 2nd machine with -v and -O2 options:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
COLLECT_GCC_OPTIONS='-v' '-O2' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/cc1plus -quiet -v -D_GNU_SOURCE dmtest.cpp -quiet -dumpbase dmtest.cpp -mtune=generic -auxbase dmtest -O2 -version -o /tmp/cc6v7CNY.s
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/x86_64-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed
/usr/include
End of search list.
GNU C++ (Debian 4.4.5-8) version 4.4.5 (x86_64-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5a2e15051eaa06a84cf6320b754ba993
COLLECT_GCC_OPTIONS='-v' '-O2' '-shared-libgcc' '-mtune=generic'
as -V -Qy -o /tmp/ccL37GHG.o /tmp/cc6v7CNY.s
GNU assembler version 2.20.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.20.1-system.20100303
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O2' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/collect2 --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.4.5/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../.. /tmp/ccL37GHG.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.4.5/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crtn.o
What's the reason of such behavior? Is my code incorrect or it's a bug in gcc 4.4.5?

Answer 1

This is type punning and it is therefore undefined behavior. I'm surprised you're not getting warnings about it.
It normally works the way you expect, of course, but it is still undefined behavior.
To get around the undefined behavior part you can cast to a char * and read each byte in succession. Does this fix the behavior you are seeing?

Answer 2

According to this blog entry, GCC 4.4 enforces strict aliasing rules for -O2. The type-punning access therefore results in undefined behaviour. Unfortunately, in order to get warnings for breaking strict aliasing rules, you have to compile with -Wstrict-aliasing.
Maybe the newer versions of GCC have reverted to the old behaviour and leave the decision whether to enable strict aliasing to the user.