Reproduceable on: Using built-in specs. COLLECT_GCC=gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/ia64-linux-gnu/4.6/lto-wrapper Target: ia64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-15' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --enable-plugin --enable-objc-gc --with-system-libunwind --enable-checking=release --build=ia64-linux-gnu --host=ia64-linux-gnu --target=ia64-linux-gnu Thread model: posix gcc version 4.6.3 (Debian 4.6.3-15) and Using built-in specs. COLLECT_GCC=gcc-4.7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/ia64-linux-gnu/4.7/lto-wrapper Target: ia64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libssp --disable-libitm --enable-plugin --enable-objc-gc --with-system-libunwind --enable-checking=release --build=ia64-linux-gnu --host=ia64-linux-gnu --target=ia64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) This bug manifest itself on ia64, powerpc and s390x (all Big Endian[1]) where gcc-4.6 is used and the optmized code (-O2) fails to produce correct math results. This code from libgd2:src/gd.c:clip_1d: *y1 -= m * (*x1 - mindim); where m = (double) -0.050000 *x1 = -200 mindim = 0 *y1 = 15 results in *y1 = 4, which is incorrect value, since it should be 5. Most simple workaround, which allows gcc to produce correct value: *y1 -= (int)(m * (*x1 - mindim)); Assigning to some other variable also works ok: int t; t = m * (*x1 - mindim); *y1 -= t; Compiling with -O0 also produces correct value. 1. Although SPARC, which should be B-E too, was built correctly.
Created attachment 29945 [details] Generated from gd.c, affected code is in clip_1d function
Maybe I should have said "inconsistent" and this might be related to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394
Created attachment 29946 [details] test case I can reproduce the issue on m68k: with the attached test case I get 4 on m68k-linux (big-endian), but 5 on x86_64-linux (little-endian). I don't see any conversions to char or unsigned, so I don't think PR27394 is related. The issue goes away with -ffloat-store on m68k. I haven't analyzed it further. On the big-endian armv5teb-linux-gnueabi I get 5, but it's soft-fp.
Yeah, I just came to same conclusion by reading further (PR9325), that it's not related to PR27394, because we are not hitting the boundaries of the conversion type. I understand that the resulting value depends on the time the conversion happen (e.g. when the fractional part gets discarded), but still I think there's something wrong when the result depends on the architecture and the optimization level.
I swear I have read the (non) bugs section before reporting the bug. Anyway it's do damn confusing that the result can be different on different architectures :(. *** This bug has been marked as a duplicate of bug 323 ***
(In reply to comment #5) > I swear I have read the (non) bugs section before reporting the bug. Anyway > it's do damn confusing that the result can be different on different > architectures :(. Rather on older architectures where the fpu was implemented as a stack one (both 68k and x86 are examples of this).
I'd say *y1 -= (int)(m * (*x1 - mindim)); isn't a workaround, but a reasonable thing to do (and less expensive than converting *y1 from int to floating point, doing subtraction in FPU and converting back.