Bug 57080

Summary:	Invalid optimization (-O2) when doing double -> int conversion (on big endian archs(?))
Product:	gcc	Reporter:	Ondřej Surý <ondrej>
Component:	c	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	jakub, mikpelinux
Priority:	P3
Version:	4.7.2
Target Milestone:	---
Host:		Target:
Build:		Known to work:
Known to fail:		Last reconfirmed:
Attachments:	Generated from gd.c, affected code is in clip_1d function test case

Description Ondřej Surý 2013-04-26 10:26:34 UTC

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.

Comment 1 Ondřej Surý 2013-04-26 10:27:30 UTC

Created attachment 29945 [details]
Generated from gd.c, affected code is in clip_1d function

Comment 2 Ondřej Surý 2013-04-26 11:04:19 UTC

Maybe I should have said "inconsistent" and this might be related to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394

Comment 3 Mikael Pettersson 2013-04-26 11:49:44 UTC

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.

Comment 4 Ondřej Surý 2013-04-26 12:32:20 UTC

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.

Comment 5 Ondřej Surý 2013-04-26 16:07:17 UTC

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 ***

Comment 6 Andrew Pinski 2013-04-26 16:11:38 UTC

(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).

Comment 7 Jakub Jelinek 2013-04-26 17:15:52 UTC

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.