Here is a revised test program:
#include <complex>
#include <limits>
#include <iostream>
int
main (int argc, char *argv[])
{
double x = 10.0;
std::complex<double> y {std::numeric_limits<double>::infinity (), 1.0};
std::complex<double> z1 = std::pow (x, y);
std::complex<double> z2 = std::pow (std::complex<double> (x), y);
std::complex<double> z3 = std::exp (y * std::log (x));
std::complex<double> z4 = std::exp (y * std::log (std::complex<double> (x)));
std::cout << z1 << ", "
<< z2 << ", "
<< z3 << ", "
<< z4 << std::endl;
}
And the output:
$ g++ o x x.cc && ./x
(inf,inf), (inf,nan), (inf,inf), (inf,nan)
$ clang++ stdlib=libstdc++ o x x.cc && ./x
(inf,inf), (inf,nan), (inf,inf), (inf,nan)
$ clang++ stdlib=libc++ o x x.cc && ./x
(inf,nan), (inf,nan), (inf,inf), (inf,nan)
The difference seems to be that LLVM promotes a noncomplex argument to its complex equivalent and uses 'exp(y*log(x))' on those two values. GCC computes the result as a special case for a noncomplex base and a complex exponent. Both runtimes agree on the underlying return values, they just disagree about whether 'pow(double, complex<double>)' should be computed as a special case or not.
So basically the same as this difference in Octave when built with GCC:
>> power (10, complex (inf, 1))
ans = Inf + Infi
>> power (complex (10, 0), complex (inf, 1))
ans = Inf  NaNi
If built with LLVM these will return the same thing.
I can't tell from cppreference whether this is an ambiguity in the spec or whether either one is definitively correct.

I can confirm that this bug is entirely within the LLVM libc++ standard library.
The following C++ program reflects a relevant piece of what Octave is doing in the failing test:
#include <complex>
#include <limits>
#include <iostream>
int
main (int argc, char *argv[])
{
std::complex<double> x {std::numeric_limits<double>::infinity (), 1.0};
std::complex<double> y = std::pow (10.0, x);
std::cout << y << std::endl;
}
This program prints '(inf,inf)' as expected, except when compiled with the LLVM C++ library:
mike@galago:~/src$ g++ o x x.cc && ./x
(inf,inf)
mike@galago:~/src$ clang++ stdlib=libstdc++ o x x.cc && ./x
(inf,inf)
mike@galago:~/src$ clang++ stdlib=libc++ o x x.cc && ./x
(inf,nan)
Does anyone know if this result is dictated by the C++ standard? If so, is there already an open LLVM bug report that we can link to?

When octave compiled with clang and llvm's libc++ library
(which is usually the case on macOS), the test general/logspace.m
fails:
octave:1> test general/logspace.m
***** assert (logspace (Inf + 1i, Inf + 1i, 3), repmat (complex (Inf,Inf), [1, 3]))
!!!!! test failed
ASSERT errors for: assert (logspace (Inf + 1i, Inf + 1i, 3),repmat (complex (Inf, Inf), [1, 3]))
Location  Observed  Expected  Reason
(1) Inf+NaNi Inf+Infi 'NaN' mismatch
(2) Inf+NaNi Inf+Infi 'NaN' mismatch
(3) Inf+NaNi Inf+Infi 'NaN' mismatch
This particular case is on Fedora 29, clang 7.0.1 libc++ 7.0.0.
hg id ada14ef3067f (stable)
The test passes when octave compiled with clang and libstdc++.
Dmitri.

