yeputons's blog

One more GCC bug (#323)
By yeputons, 14 years ago, translation, In English
Test code that I've created on contest:
http://pastebin.com/jvkUcZx3
I think that function should return the same results if it calles with byte-to-byte equas parameters.
But in this case they are distinct.
There is one more test program from MaxBuzz:
#include <cstring>
#include <cstdio>

int f(int x) { return 1 << x; }

int main() {
for (int i = 0, j = 42; i < 1000000; ++i)
if (!memcmp(&i, &j, sizeof(int))) 
printf("%d == %d\n", f(i), f(j));
return 0;
}
In this case f(j) is calculated on optimization phase, but f(i) and memcpy are calculated at run time. Optimizer thinks that 1 << 42 = 0, but CPU thinks that 1 << 42 = 1024.
This isn't a bug, because 1 << 42 is undefined.

Compiling with MSVC++ fixes this bug.

COLLECT_GCC=C:\Soft\MinGW\bin\gcc.EXE
COLLECT_LTO_WRAPPER=c:/soft/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 (GCC)

Intel Core i3 M350 (x86)

UPD. I've tried it on CF servers. Bug is alive
UPD2. There is additional requirement: use optimizer (-O1/-O2)
UPD3. Two absolutely same submits got different outcomes: GCC - WA14 (240112), MSVC++ - OK (240115). Problem B from CF#49.

I'll be glad if you tell me my mistakes in English.
  • Vote: I like it
  • +43
  • Vote: I do not like it

14 years ago, # |
  Vote: I like it 0 Vote: I do not like it
On Ubuntu 10.10 x86_64, which uses gcc 4.4, I get "20971520 == 20971520" as output, no matter which level of optimization I use, so either the bug has been introduced in 4.5 or it occurs only on Windows MINGW.
I also experienced the bug at CF#49-B, but I was lucky that it already failed during the pretest.
→ Reply
  • 14 years ago, # ^ |
      Vote: I like it 0 Vote: I do not like it
    Maybe on Ubuntu 10.10 x86_64 gcc generates x64-binaries. Could someone run it on 32-bit linux?
    On mingw-w64 it also works fine.
    → Reply
    • 14 years ago, # ^ |
      ← Rev. 2   Vote: I like it +5 Vote: I do not like it
      The bug works on gcc-4.4-32bit here with -O1/O2/O3 and the program works with -O0.
      → Reply
14 years ago, # |
← Rev. 2   Vote: I like it +5 Vote: I do not like it
When I compile it with "g++ -m32 -O2 gccbugtest.cpp" I indeed get the wrong result. It seems that only 32-bit code generation is bugged, but it's bugged on Linux too.
edit: The second test gives "1024 == 1024" even with 32-bit.
→ Reply
14 years ago, # |
  Vote: I like it +5 Vote: I do not like it
-ffloat-store compiler flag solves the floating-point problem for me. The other one I don't have.

Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --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 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
→ Reply
14 years ago, # |
  Vote: I like it +10 Vote: I do not like it
Just to clarify: these are not bugs. 1<<42 is undefined behaviour, and the other one is also well-known.
→ Reply