From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-372850-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 20794 invoked by alias); 3 Nov 2011 23:58:13 -0000
Received: (qmail 20534 invoked by uid 22791); 3 Nov 2011 23:58:12 -0000
X-SWARE-Spam-Status: No, hits=-2.9 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Nov 2011 23:57:58 +0000
From: "kreckel at ginac dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
Date: Thu, 03 Nov 2011 23:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kreckel at ginac dot de
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.6.3
X-Bugzilla-Changed-Fields:
Message-ID: <bug-50880-4-8p0EGGnmZB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50880-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50880-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
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
X-SW-Source: 2011-11/txt/msg00346.txt.bz2

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

--- Comment #23 from Richard B. Kreckel <kreckel at ginac dot de> 2011-11-03 23:57:55 UTC ---
(In reply to comment #16)
> Well, I guess this would be most of it:
> 
>   template<typename _Tp>
>     std::complex<_Tp>
>     __complex_acosh(const std::complex<_Tp>& __z)
>     {
>       return _Tp(2.0) * std::log(std::sqrt(_Tp(0.5) * (__z + _Tp(1.0)))
>                  + std::sqrt(_Tp(0.5) * (__z - _Tp(1.0))));
>     }

[Sorry for my temporary absence.]

For future reference, some final remarks:
* Yes, that is a good implementation for this "fallback".
  It relies on __z - _Tp(1.0) not "mutating" the sign of __z's imag part.
* If the complex log does not do the right thing, all is lost anyways
  (besides, __complex_asinh relies on it, too).
* My patch BC1 was flawed. It contains code trying to work around a ctor doing
  multiplication (fixed in PR48760)
* My patch BC2 was flawed for the same reason: __z - __one doesn't preserve
  the sign of __z's imag part.

Looks good. Thanks!