[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Priority|P3                          |P2
           Severity|normal                      |major

--- Comment #26 from kargl at gcc dot gnu.org ---
Any chance a libstdc++ person will commit the supplied patches?

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[redi at gcc dot gnu.org]

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

--- Comment #27 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Not in stage 4.

[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct

[redi at gcc dot gnu.org]

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

--- Comment #28 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to kargl from comment #21)
> Created attachment 46102 [details]
> fix g++ problem with sqrt(z) where z is complex and imag(z) = -0

This one assumes copysign is valid for arguments of type _Tp, which is only
true for float, double and long double. std::pow might make sense for complex
integers, but seems to be already broken, so this doesn't make it any worse
there.

To preserve support for user-defined numeric types (and decimal floats?) we
could add an overloaded helper for copysign which retains the `__x < _Tp()`
check for the generic overload and uses copysign for floating point types.


(In reply to kargl from comment #23)
> Created attachment 46105 [details]
> fix g++ problem with pow(z,0.5) where imag(z) = -0.
> 
> This patch has only been tested with the original test provided by the
> reporter.

This one makes me a little uncomfortable with the use of abs, but we already
use that elsewhere (and inconsistently qualify it as std::abs). Again, this
doesn't seem to make anything worse w.r.t our support for types other than
float, double and long double.