[RFC] What to do for complex::pow(0, 0)

[Paolo Carlini <pcarlini at suse dot de>]

Hi,

as you all know well, I mean to improve a bit the consistency of our 
implementation in this special case, strictly speaking not regulated by 
the C++ standard, I briefly remind you.

In my opinion, it's the right time, because finally Roger's work on 
__builtin_signbit is in, thus all the options are viable. Also, we have 
got a new PR and the use that we are already making of __builtin_cpow 
makes the consistency issue more pressing.

In short, I see two possible options, here:

1- Leave everything mostly as-is, besides a tweak to __complex_pow(const 
complex<>&, const complex<>&), removing the check for __x == T(). This 
means that we are going to return, rather consistently and reliably, 
(nan, nan). I say -rather- because, in case the underlying cpow 
exploited by __builtin_cpow actually returns (1, 0) we are in "trouble". 
AFAIK, this is rather uncommon, but happens for an HP libc, for instance.

2- Tweak complex::pow to return consistently (1, 0). This means 
exploting the new __builtin_signbit in pow(const complex<>&, const T&) 
and adding/tweaking a few conditionals to handle this special case (*)

As you probably know well by now ;), I prefer option 2, seems more 
consistent with C99 on real pow, etc., but it's slightly more tricky to 
implement, still absolutely doable (I should check, however, that 
__builtin_signbit works well also for IBM 128-bit long double format, 
I'm asking Roger, to be sure)

Ah, if you are curious, Icc/Dinkum returns either (0, 0) or (1.0) (case 
of pow(const T&, const complex<>&)), puzzling.

Thanks for any feedback,
Paolo.

(*) This solution would also fix, as a side-effect, that (rather low 
priority) PR mentioned above because we would avoid computing atan2(0, 
0), which is not guaranteed to be 1 in non-C99 libcs.