Bug 49949 - wrong sign for product of complex<double> and double with -O2
Summary: wrong sign for product of complex<double> and double with -O2
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.5.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 28408
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-02 19:17 UTC by Ilker R Capoglu
Modified: 2021-08-10 01:32 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-08-03 09:40:46


Attachments
The preprocessed file with the STL and blitz++ headers. (bzip2'd) (113.47 KB, application/x-bzip)
2011-08-03 16:34 UTC, Ilker R Capoglu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ilker R Capoglu 2011-08-02 19:17:59 UTC
With the -O2 flag and in a very specialized circumstance, the product of a complex<double> and a double has the wrong sign.

The problem arises when the blitz++ array library is used. (http://www.oonumerics.org/blitz/) Unfortunately, I could not prune out all the references to the unnecessary C++ standard libraries. The size of the .ii file is therefore pretty big. I hope the report will still be useful.

The output of the executable gcc_complex_bug should be

(-0.0,-1.0)x100.0=(0.0,100.0)

which shows the wrong sign for the product.

The following is the output of "g++ -v -save-temps -I. -O2 -o gcc_complex_bug gcc_complex_bug.cpp"

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --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.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-I.' '-O2' '-o' 'gcc_complex_bug' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/cc1plus -E -quiet -v -I. -D_GNU_SOURCE gcc_complex_bug.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -march=x86-64 -O2 -fpch-preprocess -fstack-protector -o gcc_complex_bug.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/../../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 .
 /usr/include/c++/4.5
 /usr/include/c++/4.5/x86_64-linux-gnu
 /usr/include/c++/4.5/backward
 /usr/local/include
 /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include
 /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-I.' '-O2' '-o' 'gcc_complex_bug' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/cc1plus -fpreprocessed gcc_complex_bug.ii -quiet -dumpbase gcc_complex_bug.cpp -mtune=generic -march=x86-64 -auxbase gcc_complex_bug -O2 -version -fstack-protector -o gcc_complex_bug.s
GNU C++ (Ubuntu/Linaro 4.5.2-8ubuntu4) version 4.5.2 (x86_64-linux-gnu)
	compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 3.0.0-p8, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu/Linaro 4.5.2-8ubuntu4) version 4.5.2 (x86_64-linux-gnu)
	compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 3.0.0-p8, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1a8763bcd4db37297f4ae8b8aab36cf0
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-I.' '-O2' '-o' 'gcc_complex_bug' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -V -Qy --64 -o gcc_complex_bug.o gcc_complex_bug.s
GNU assembler version 2.21.0 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.21.0.20110327
COMPILER_PATH=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/:/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/:/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/:/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/:/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/:/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/../../../:/lib/:/usr/lib/:/usr/lib/x86_64-linux-gnu/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-I.' '-O2' '-o' 'gcc_complex_bug' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/collect2 --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o gcc_complex_bug /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/../../../crt1.o /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/../../../crti.o /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/crtbegin.o -L/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2 -L/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/../../.. -L/usr/lib/x86_64-linux-gnu gcc_complex_bug.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/crtend.o /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/../../../crtn.o
Comment 1 Richard Biener 2011-08-03 09:40:46 UTC
An attachment is missing.  Please try to create a small self-contained
testcase using <complex>.
Comment 2 Ilker R Capoglu 2011-08-03 16:20:53 UTC
(In reply to comment #1)
> An attachment is missing.  Please try to create a small self-contained
> testcase using <complex>.

Sorry, I think it didn't get uploaded because it was above 1000k. I'll try and get a smaller .ii file.

Thanks!
Comment 3 Jonathan Wakely 2011-08-03 16:27:23 UTC
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction is useful

if you can't reduce it then using gzip or bzip2 might make it small enough to attach
Comment 4 Ilker R Capoglu 2011-08-03 16:32:47 UTC
(In reply to comment #3)
> http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction is useful
> 
> if you can't reduce it then using gzip or bzip2 might make it small enough to
> attach

I actually read the instructions very carefully and managed to go through a lot of it. The problem is that (a) I'm not so familiar with the internals of the blitz++ library to prune out the crud effectively (b) the STL headers are buried so deep into blitz++ that it takes a blitz++ developer to take them out.

I'll try to gzip the file and resubmit, though.
Comment 5 Ilker R Capoglu 2011-08-03 16:34:31 UTC
Created attachment 24906 [details]
The preprocessed file with the STL and blitz++ headers. (bzip2'd)
Comment 6 Paolo Carlini 2011-09-28 14:57:26 UTC
I can reproduce the problem with gcc4.5.x and 4.6.x, but mainline (would be 4.7.0) is fine. Did it ever work for you with older compilers? Because if isn't a regression, I'm afraid that not much will happen. But would be still interesting to understand what fixed the problem in mainline...
Comment 7 Paolo Carlini 2011-09-28 15:10:47 UTC
HJ, any chance you can find what fixed this? Doesn't seem a regression, but it's an annoying issue anyway, if the patch is simple...
Comment 8 H.J. Lu 2011-09-28 15:54:09 UTC
(In reply to comment #0)
> With the -O2 flag and in a very specialized circumstance, the product of a
> complex<double> and a double has the wrong sign.
> 
> The problem arises when the blitz++ array library is used.
> (http://www.oonumerics.org/blitz/) Unfortunately, I could not prune out all the
> references to the unnecessary C++ standard libraries. The size of the .ii file
> is therefore pretty big. I hope the report will still be useful.
> 
> The output of the executable gcc_complex_bug should be
> 
> (-0.0,-1.0)x100.0=(0.0,100.0)
> 

I also got

(-0.0,-1.0)x100.0=(-0.0,-100.0)

with GCC 4.7.0 revision 179164.  Why should we get (0.0,100.0)?
Comment 9 Paolo Carlini 2011-09-28 16:02:05 UTC
HJ, I think the correct output, showing that we are *not* miscompiling or something is:

(-0.0,-1.0)x100.0=(-0.0,-100.0)

exactly what you are seeing. The problem is, with 4.6 we get:

(-0.0,-1.0)x100.0=(0.0,100.0)

which is wrong. When that changed?
Comment 10 H.J. Lu 2011-09-28 18:03:50 UTC
It is fixed by revision 172430:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00625.html
Comment 11 Paolo Carlini 2011-09-29 15:26:30 UTC
Doesn't seem to make much sense, but thanks, anyway.
Comment 12 Paolo Carlini 2011-09-29 15:27:56 UTC
Maybe Honza has ideas about this...
Comment 13 Jan Hubicka 2011-09-30 16:26:46 UTC
> Maybe Honza has ideas about this...
That patch affect inlining decisions, but should not affect correctness. So it seems that the bug whatever it is just gone latent.

Honza
Comment 14 Paolo Carlini 2011-09-30 20:27:36 UTC
Hug :( We should really distill a much, much smaller snippet and analyze what is really going wrong. Maybe Jakub could help?