[Bug c++/64677] New: incorrect result with complex division?

[Bug c++/64677] New: incorrect result with complex division?

[spatel at rotateright dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677

            Bug ID: 64677
           Summary: incorrect result with complex division?
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: spatel at rotateright dot com

I'm not sure if this is a bug at -O0, at -O1 (in MPFR because all math is
folded out in this case?), or neither:

#include <complex>
#include <iostream>
#include <iomanip>

int main()
{
    std::complex<double> c(-61.887073591767951,-60.052083270252012);
    double a = (1.0 / c).real();

    std::cout << std::setprecision(17) << " " << a << std::endl;
}

$ g++ complex_div.cpp -O0 -std=c++11
$ ./a.out 
 -0.0083223357032193145
$ g++ complex_div.cpp -O1 -std=c++11
$ ./a.out 
 -0.0083223357032193128


Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/4.9.2/lto-wrapper
Target: x86_64-apple-darwin14.0.0
Configured with: ../gcc-4.9-20141029/configure --enable-languages=c++,fortran
Thread model: posix
gcc version 4.9.2 20141029 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.0' '-O1' '-std=c++11' '-v'
'-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/4.9.2/cc1plus -quiet -v
-D__DYNAMIC__ 22241.cpp -fPIC -quiet -dumpbase 22241.cpp
-mmacosx-version-min=10.10.0 -mtune=core2 -auxbase 22241 -O1 -std=c++11
-version -o /var/folders/k1/5fqvbm0n1zj6kjp0s9p18rm40000gn/T//ccaWfRcp.s
GNU C++ (GCC) version 4.9.2 20141029 (prerelease) (x86_64-apple-darwin14.0.0)
    compiled by GNU C version 4.9.2 20141029 (prerelease), GMP version 6.0.0,
MPFR version 3.1.2-p10, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/../../../../x86_64-apple-darwin14.0.0/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/

/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/../../../../include/c++/4.9.2

/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/../../../../include/c++/4.9.2/x86_64-apple-darwin14.0.0

/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/../../../../include/c++/4.9.2/backward
 /usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/include-fixed
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C++ (GCC) version 4.9.2 20141029 (prerelease) (x86_64-apple-darwin14.0.0)
    compiled by GNU C version 4.9.2 20141029 (prerelease), GMP version 6.0.0,
MPFR version 3.1.2-p10, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c0a1d89bdb8ef292bcb2f0d5b923240f
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.0' '-O1' '-std=c++11' '-v'
'-shared-libgcc' '-mtune=core2'
 as -arch x86_64 -force_cpusubtype_ALL -o
/var/folders/k1/5fqvbm0n1zj6kjp0s9p18rm40000gn/T//ccOTSBAQ.o
/var/folders/k1/5fqvbm0n1zj6kjp0s9p18rm40000gn/T//ccaWfRcp.s
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/4.9.2/:/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/4.9.2/:/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/:/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.0' '-O1' '-std=c++11' '-v'
'-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/4.9.2/collect2 -dynamic -arch
x86_64 -macosx_version_min 10.10.0 -weak_reference_mismatches non-weak -o a.out
-L/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2
-L/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/../../..
/var/folders/k1/5fqvbm0n1zj6kjp0s9p18rm40000gn/T//ccOTSBAQ.o -lstdc++
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v
collect2 version 4.9.2 20141029 (prerelease)
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.10.0
-weak_reference_mismatches non-weak -o a.out
-L/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2
-L/usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2/../../..
/var/folders/k1/5fqvbm0n1zj6kjp0s9p18rm40000gn/T//ccOTSBAQ.o -lstdc++
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v
@(#)PROGRAM:ld  PROJECT:ld64-241.9
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h
armv6m armv7m armv7em
Library search paths:
    /usr/local/lib/gcc/x86_64-apple-darwin14.0.0/4.9.2
    /usr/local/lib
    /usr/lib
    /usr/local/lib
Framework search paths:
    /Library/Frameworks/
    /System/Library/Frameworks/

[Bug c++/64677] incorrect result with complex division?

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
One part is different.  Most likely not a bug.  Division really depends on
fused multiple add to get good results IIRC.

[Bug c++/64677] incorrect result with complex division?

[spatel at rotateright dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677

--- Comment #2 from Sanjay Patel <spatel at rotateright dot com> ---
This is on plain x86-64 with SSE (before the addition of any FMA instructions),
so lack of FMA must be accounted for?

The answers differ in the last digit / ULP. Is there some standard or golden
implementation that will answer which answer is correct?

[Bug c++/64677] incorrect result with complex division?

[maltsevm at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677

Mikhail Maltsev <maltsevm at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maltsevm at gmail dot com

--- Comment #3 from Mikhail Maltsev <maltsevm at gmail dot com> ---
Probably calculating with higher precision will give correct result. Output of
Wolfram Alpha:

-O0:
convert -0.0083223357032193145 to binary
-1.00010000101101001100111111010101111110001111010101101111110000100111001001000000101110010001111111000010000110010110110001111..._2×2^-7
| hexadecimal value
IEEE double-precision number | 578f5ffd4c0b81bf 
(assuming little-endian byte ordering)

-O1:
convert -0.0083223357032193128 to binary
-1.00010000101101001100111111010101111110001111010101100000000101000110111101001110010111111111111111010110100111010111010010011..._2×2^-7
| hexadecimal value
IEEE double-precision number | 568f5ffd4c0b81bf 
(assuming little-endian byte ordering)

Wolfram Alpha's calculation:
binary(re(1/(-61.887073591767951 -60.052083270252012i)))
-1.0001000010110100110011111101010111111000111101010110000111101100101010111110001101011011011011010000000101100000101111101111..._2×2^-7
| hexadecimal value
IEEE double-precision number | 568f5ffd4c0b81bf 
(assuming little-endian byte ordering)

So, compile-time result is more precise. BTW, what does the disassembly look
like?
>From gcc-bugs-return-473964-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 20 05:40:11 2015
Return-Path: <gcc-bugs-return-473964-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4604 invoked by alias); 20 Jan 2015 05:40:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4520 invoked by uid 48); 20 Jan 2015 05:40:02 -0000
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/64282] [5 Regression] ICE in gimple_get_virt_method_for_vtable, at gimple-fold.c:5635
Date: Tue, 20 Jan 2015 05:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64282-4-pun8b3muw6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64282-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64282-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg01958.txt.bz2
Content-length: 831

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd282

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The reduced testcase does not seem to reproduce for me.  The ICE is however
just overactive sanity check - the program is invalid and accesses random data
as vtable pointer. In this case we can just optimize to unreachable instead of
ICEing. I am testing the following:

Index: gimple-fold.c
==================================================================--- gimple-fold.c       (revision 219876)
+++ gimple-fold.c       (working copy)
@@ -5649,7 +5649,6 @@ gimple_get_virt_method_for_vtable (HOST_
   if (TREE_CODE (v) != VAR_DECL
       || !DECL_VIRTUAL_P (v))
     {
-      gcc_assert (in_lto_p);
       /* Pass down that we lost track of the target.  */
       if (can_refer)
        *can_refer = false;

[Bug libgcc/64677] incorrect result with complex division?

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libgcc

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
libgcc implements complex division.  I'm quite sure it doesn't get 0.5ulp
precision (nor non-default rounding modes) correctly.

[Bug libgcc/64677] incorrect result with complex division?

[spatel at rotateright dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677

--- Comment #5 from Sanjay Patel <spatel at rotateright dot com> ---
(In reply to Mikhail Maltsev from comment #3)
> So, compile-time result is more precise. BTW, what does the disassembly look
> like?

In the -O0 case, it looks like all of the math is handled in:
     call    ___ieee_divdc3

In the -O1 case, the result is precomputed and loaded from constant pool:
LC1:
        .long   4250898262
        .long   -1082062004


Is Wolfram Alpha considered the authoritative answer? Or is there some IEEE
reference implementation that we can consult for this kind of question?

[Bug libgcc/64677] incorrect result with complex division?

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Sanjay Patel from comment #5)
> (In reply to Mikhail Maltsev from comment #3)
> > So, compile-time result is more precise. BTW, what does the disassembly look
> > like?
> 
> In the -O0 case, it looks like all of the math is handled in:
>  	call	___ieee_divdc3


Is this the one in libgcc or part of Apple's libc?  If it is part of Apple's
libc, then the bug is there.  Apple's libc implementation of ___ieee_divdc3 has
known issues IIRC.
>From gcc-bugs-return-474099-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 20 19:10:25 2015
Return-Path: <gcc-bugs-return-474099-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13945 invoked by alias); 20 Jan 2015 19:10:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13906 invoked by uid 48); 20 Jan 2015 19:10:20 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgcc/64677] incorrect result with complex division?
Date: Tue, 20 Jan 2015 19:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgcc
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64677-4-aJqyNDPD46@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64677-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64677-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg02093.txt.bz2
Content-length: 835

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Sanjay Patel from comment #5)
> > (In reply to Mikhail Maltsev from comment #3)
> > > So, compile-time result is more precise. BTW, what does the disassembly look
> > > like?
> > 
> > In the -O0 case, it looks like all of the math is handled in:
> >  	call	___ieee_divdc3
> 
> 
> Is this the one in libgcc or part of Apple's libc?  If it is part of Apple's
> libc, then the bug is there.  Apple's libc implementation of ___ieee_divdc3
> has known issues IIRC.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333 .  So ___ieee_divdc3 is
always GCC's libgcc implementation.

Can you try this under Linux too, just to double check there?
>From gcc-bugs-return-474100-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 20 19:14:06 2015
Return-Path: <gcc-bugs-return-474100-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16301 invoked by alias); 20 Jan 2015 19:14:05 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16142 invoked by uid 48); 20 Jan 2015 19:13:59 -0000
From: "rth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure
Date: Tue, 20 Jan 2015 19:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jiwang at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64669-4-qF36NE4YUr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64669-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64669-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg02094.txt.bz2
Content-length: 615

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd669

--- Comment #8 from Richard Henderson <rth at gcc dot gnu.org> ---
Indeed, if I force used_in_cond_stmt_p to return false, which forces
the use of the emit_cstore path, which means we return a proper
boolean value instead of a CCmode value, the test case doesn't ICE.

Moreover, combine does in fact remove the redundant compare and we
are left with

        cmp     w0, 39
        ccmp    w0, 10, 4, ne
        bne     .L19

I think I was wrong to approve the ccmp patch with the used_in_cond_stmt_p
logic in the first place, and that it should all be removed.

[Bug libgcc/64677] incorrect result with complex division?

[spatel at rotateright dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677

--- Comment #8 from Sanjay Patel <spatel at rotateright dot com> ---
(In reply to Andrew Pinski from comment #7) 
> Can you try this under Linux too, just to double check there?

Wow, that other bug shows that there are a lot of variables here. 

I don't know what to make of this: First, I'm just trying g++ 4.8.2 on Ubuntu
14.04 because that's what I have available at the moment. 

It seems I don't need the -std=c++11 flag as I do on OS X? But using that flag
changes the result at -O1!

$ g++ -O0 complex_div.cpp ; ./a.out
 -0.0083223357032193145  

(does not match Wolfram)

$ g++ -O1 complex_div.cpp ; ./a.out
 -0.0083223357032193145  

(does not match Wolfram)

$ g++ -O0 complex_div.cpp -std=c++11 ; ./a.out
 -0.0083223357032193145

(does not match Wolfram)

$ g++ -O1 complex_div.cpp -std=c++11 ; ./a.out
 -0.0083223357032193128

(matches Wolfram...but why is this different?!)

[Bug libgcc/64677] incorrect result with complex division?

[spatel at rotateright dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677

--- Comment #9 from Sanjay Patel <spatel at rotateright dot com> ---
(In reply to Sanjay Patel from comment #8)
> It seems I don't need the -std=c++11 flag as I do on OS X?

Actually, I screwed that up. We don't need that flag on OS X either...and
thankfully, the behavior matches Linux. This is on the same OS X (10.10) that I
was testing on when filing the bug:

$ g++ -O0 complex_div.cpp ; ./a.out 
 -0.0083223357032193145

$ g++ -O1 complex_div.cpp ; ./a.out 
 -0.0083223357032193145

$ g++ -O0 complex_div.cpp -std=c++11 ; ./a.out 
 -0.0083223357032193145

$ g++ -O1 complex_div.cpp -std=c++11 ; ./a.out 
 -0.0083223357032193128

So there are (at least) 2 questions:
1. Why does the answer change based on the -std?
2. What is the correct answer?

[Bug libgcc/64677] incorrect result with complex division?

[spatel at rotateright dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677

--- Comment #11 from Sanjay Patel <spatel at rotateright dot com> ---
(In reply to Mikhail Maltsev from comment #10)
> C++11 supports constexpr (and std::complex has constexpr constructor).

Ah, that makes sense. Yes, we're only generating the answer using MPFR with
c++11 and optimization. So I think this comes down to an implementation
difference between libgcc and MPFR.


> By the way, according to C++ standard, precision of floating point numbers
> is implementation-defined.

Hmmm...so we still don't know which answer is correct or if both answers are
acceptable?