[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |middle-end

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
IMHO the most interesting bit is that it only happens for long double. Anyway,
this is neither C++ library nor front-end, either middle-end or libc, likely
the former because on my machine neither clang++ nor icc has the issue while
the underlying libc is the same glibc. Anyway, reduced:

  __builtin_expl (- 1 / 0.0)

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Or, more elegantly:

  __builtin_expl (-__builtin_huge_vall ())

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P2

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uros at gcc dot gnu.org

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Uros, can you help me with this annoying wrong-code?

I suspect the back end could be also involved because it happens only for long
double and I didn't see anything special for long double in builtins.c

(if isn't clear enough, the expression in Comment #1 or #2 evaluates to -nan
instead of 0)

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Paolo Carlini from comment #3)

> I suspect the back end could be also involved because it happens only for
> long double and I didn't see anything special for long double in builtins.c

-funsafe-math-optimizations are used here:

'-funsafe-math-optimizations'

     Allow optimizations for floating-point arithmetic that (a) assume
     that arguments and results are valid and (b) may violate IEEE or
     ANSI standards.  When used at link-time, it may include libraries
     or startup files that change the default FPU control word or other
     similar optimizations.

The __builtin_expl is expanded to:

        flds    .LC0(%rip)
        fld     %st(0)
        frndint
(*)     fsubr   %st, %st(1)
        fxch    %st(1)
        f2xm1
        fadds   .LC2(%rip)
        fscale
        fstp    %st(1)
        fstpt   16(%rsp)

and with fsubr, we hit Inf - Inf, which is by definition NaN.

Obviously, this testcase exposes the unsafe part of
-funsafe-math-optimizations. Without this option everything works OK.
>From gcc-bugs-return-426718-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 25 15:47:44 2013
Return-Path: <gcc-bugs-return-426718-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4855 invoked by alias); 25 Jul 2013 15:47:43 -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 4745 invoked by uid 48); 25 Jul 2013 15:47:41 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns  (-nan,-nan)
Date: Thu, 25 Jul 2013 15:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57974-4-SsdvYbi6Eo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57974-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57974-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: 2013-07/txt/msg01225.txt.bz2
Content-length: 294

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW974

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> ---
But isn't this a bug? I mean, naively, what do we gain from the optimization
point of view from not evaluating as 0 in any case? And why it happens only for
long double?

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

--- Comment #6 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Paolo Carlini from comment #5)
> But isn't this a bug? I mean, naively, what do we gain from the optimization
> point of view from not evaluating as 0 in any case? And why it happens only
> for long double?

Because long double always goes through x87. doubles and floats will fail your
test with -m32 or -mfpmath=387 in addition to -funsafe-math-optimizations.

BTW: The test does use infinty (which is IEEE thingy), and there is explicit
warning that -funsafe-math-optimizations will violate these rules.
>From gcc-bugs-return-426721-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 25 16:01:28 2013
Return-Path: <gcc-bugs-return-426721-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27836 invoked by alias); 25 Jul 2013 16:01:28 -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 27735 invoked by uid 48); 25 Jul 2013 16:01:25 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57986] call to local "bind" template function called std::bind without "using" any namespace.
Date: Thu, 25 Jul 2013 16:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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: bug_status resolution
Message-ID: <bug-57986-4-M71aUxeiGq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57986-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57986-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: 2013-07/txt/msg01228.txt.bz2
Content-length: 774

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW986

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to yangzhe1990 from comment #7)
> Thanks. Now only one question left. Why removing <algorithm> could disable
> the ADL?

<algorithm> is probably including <functional>

> BTW, in c++03, to avoid the const_cast, is writing a shared_ptr the right
> choice?

Make the type non-copyable, and if you need to pass it around then use
shared_ptr<thread>

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo.carlini at oracle dot com

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> ---
However it's still not clear to me why this inconsistency doesn't happen with
clang or icc, for example. I'm not convinced we are doing our job in the best
way and I don't think we are going to make users happy. It's pretty easy to
internally call in the c++ library or in user code another builtin which does
produce a -inf without the user knowing and then passes it to a function like
exp. If some of our builtins produce something which our other builtins aren't
able to handle consistently we are looking for trouble.

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

--- Comment #8 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Paolo Carlini from comment #7)
> However it's still not clear to me why this inconsistency doesn't happen
> with clang or icc, for example. I'm not convinced we are doing our job in
> the best way and I don't think we are going to make users happy. It's pretty
> easy to internally call in the c++ library or in user code another builtin
> which does produce a -inf without the user knowing and then passes it to a
> function like exp. If some of our builtins produce something which our other
> builtins aren't able to handle consistently we are looking for trouble.

But, then -funsafe-math-optimizations shouldn't be used.
>From gcc-bugs-return-426725-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 25 16:15:17 2013
Return-Path: <gcc-bugs-return-426725-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26134 invoked by alias); 25 Jul 2013 16:15:17 -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 26047 invoked by uid 48); 25 Jul 2013 16:15:14 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns  (-nan,-nan)
Date: Thu, 25 Jul 2013 16:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57974-4-BJrtZsC5XN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57974-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57974-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: 2013-07/txt/msg01232.txt.bz2
Content-length: 245

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW974

--- Comment #9 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Or maybe should be made a little weaker / safer? Are you 100% sure we are
beating performancewise clang and icc on this?

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at gcc dot gnu.org

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Gaby, do you have an opinion on this? Irrespective of the long double issue, do
you want me to re-enable (contra LWG 844) the pow(const complex<>&, int)
overload in C++11 mode? If you think so, I can do it.

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[gdr at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

--- Comment #11 from Gabriel Dos Reis <gdr at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #10)
> Gaby, do you have an opinion on this? Irrespective of the long double issue,
> do you want me to re-enable (contra LWG 844) the pow(const complex<>&, int)
> overload in C++11 mode? If you think so, I can do it.

I think pow(const complex<T>&,int) is lesser evil.  So, yes, I will support
re-enabling it.  What would we run afoul, except the obvious standard letter? 
Would we be computing something wrong?

-- Gaby

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

--- Comment #12 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Agreed, let's do it.

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|paolo.carlini at oracle dot com    |

--- Comment #13 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Done.

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

--- Comment #15 from Paolo Carlini <paolo.carlini at oracle dot com> ---
However, there is *nothing* new about that. I still do believe there is a
middle-end issue here, if only because clang and icc are fine.

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

--- Comment #17 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Henner Sudek from comment #14)
> First i want to thank you all for the quick response and solving my problem.
> I just want to point out that std::pow(std::complex<long double>(0,0),1.)
> still returns nan. Maybe there is an way to unify the behavior of these
> functions?

One thing that may be missing is a middle-end optimization that detects that
the second argument to cpow is a simple constant (we have that for the real
pow). But that wouldn't help for a runtime value of 1.

(In reply to Paolo Carlini from comment #16)
> Also, in practice, I think it's *very* hard to explain to the users why long
> double is so special, why the middle-end can't handle it in complete analogy
> with float and double. And since clang and icc are *already* doing it,
> apparently, you can't just tell them, vaguely, "it's very tough to
> implement" or "performance would be horrible" or something similar.

Did you benchmark both versions? That would help move the conversation...

I really don't think we want to give users too high expectations about
-ffast-math. When you use complex numbers and the pow function, you know that
along the negative real axis be dragons. Expecting -ffast-math to give standard
results there is wrong, even if you may be lucky sometimes. We do a number of
other transformations with fast-math that can be very wrong. Like we could have
rounded the first argument of pow to a very small negative number before the
call ;-)

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

--- Comment #18 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Couple of clarifications: this doesn't go through cpow at all, the second
argument isn't complex; this isn't -ffast-math, and in general in my experience
whatever you throw at clang and icc (in fact, clang++ accepts the very same -f
gcc accepts) like -Ofast, it never happens that exp(-inf) becomes nan (now I
don't have the time to actually run benchmarks but since we are talking about
compile-time constants I don't think we are beating them performance-wise on
this); why long double is so special for exp(-inf), I don't think we can make a
case for that, in terms of consistency or x87 crazyness (we are comparing also
to icc not to a random compiler from people not really knowing the
architecture).

But sorry I'm not going to contribute much more to this discussion, at the
moment I don't think I'm able to make the compiler concretely better and it
only would make me nervous.

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glisse at gcc dot gnu.org

--- Comment #19 from Marc Glisse <glisse at gcc dot gnu.org> ---
Ah, I think I understand now. For the exp function, getting an infinite
argument violates the assumptions of fast-math, so anything goes (though of
course it would be good to have the right result if it wasn't slower). But the
user used the pow function, which even if it has a branch cut along the
negative axis remains close to 0 around 0. The C++ standard does define pow in
terms of exp and log, but I understand why it is surprising in this case.

Ok, forget I posted anything, I am not taking any side...

Ah, your reply arrived in the meantime:

(In reply to Paolo Carlini from comment #18)
> Couple of clarifications: this doesn't go through cpow at all, the second
> argument isn't complex;

Might have made sense to convert the second argument to a complex, call
__builtin_cpow and let the middle-end deal with it.

> this isn't -ffast-math,

-funsafe-math-optimizations is pretty close to -ffast-math...

> and in general in my
> experience whatever you throw at clang and icc (in fact, clang++ accepts the
> very same -f gcc accepts) like -Ofast, it never happens that exp(-inf)
> becomes nan (now I don't have the time to actually run benchmarks

If someone does, that would help.

> but since
> we are talking about compile-time constants I don't think we are beating
> them performance-wise on this);

Don't we handle constant propagation using libmpc? That looks like a bug to me,
we should indeed compute a constant in the middle-end.

> why long double is so special for exp(-inf),

It isn't long double that is special, it is float/double that get lucky ;-)
Though I admit that this surprising behavior is only ok if it comes with a
significant speed gain.

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|glisse at gcc dot gnu.org          |

--- Comment #20 from Marc Glisse <glisse at gcc dot gnu.org> ---
For reference, on my system, the performance ratio between a call to the libc
expl and the inlined unsafe code is roughly 1.6.

[Bug middle-end/57974] std::pow(std::complex<long double>(0),1) returns (-nan,-nan)

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
                 CC|                            |msebor at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-04-13

--- Comment #21 from Martin Sebor <msebor at gcc dot gnu.org> ---
This is still unconfirmed, 7 years after it was reported.  If there is an
outstanding bug it should be confirmed, otherwise, can the issue be resolved?
(Just trying to make progress if/where possible.)