[flang] Add cpowi function to runtime and use instead of pgmath

[DavidTruby]

Summary

This patch adds a cpowi function to the flang runtime, and switches
to using that function instead of pgmath for complex number to
integer power operations.

[DavidTruby]

It looks like MSVC doesn't like what I have done here. Does anyone have any suggestions? I don't have access to a Windows install to test this myself...

[vzakhari]

In D134889#3824673, @DavidTruby wrote:

It looks like MSVC doesn't like what I have done here. Does anyone have any suggestions? I don't have access to a Windows install to test this myself...

Try renaming complex-powi.cpp into complex-powi.c.

[DavidTruby]

In D134889#3824691, @vzakhari wrote:

In D134889#3824673, @DavidTruby wrote:

It looks like MSVC doesn't like what I have done here. Does anyone have any suggestions? I don't have access to a Windows install to test this myself...

Try renaming complex-powi.cpp into complex-powi.c.

In that case I'd have to rewrite it somehow as I'm using a template in there to abstract the 4 different types we need (as the implementation is identical)
I think it might be that #include complex.h is outside the ifdef for msvc?

[vzakhari]

@klausler, can you please have a look?

flang/include/flang/Runtime/complex-wrapper.h

5 ↗

(On Diff #463931)

Please move the header comment to the beginning of the file.

flang/runtime/complex-powi.cpp

68

Please use int64_t instead of long here and below.

[vzakhari]

In D134889#3824696, @DavidTruby wrote:

In D134889#3824691, @vzakhari wrote:

In D134889#3824673, @DavidTruby wrote:

It looks like MSVC doesn't like what I have done here. Does anyone have any suggestions? I don't have access to a Windows install to test this myself...

Try renaming complex-powi.cpp into complex-powi.c.

In that case I'd have to rewrite it somehow as I'm using a template in there to abstract the 4 different types we need (as the implementation is identical)
I think it might be that #include complex.h is outside the ifdef for msvc?

I do not think the placement of #include <complex.h> matters. You will still have to include it for MSVC, and it is deprecated in C++17 as MSVC states.
You may try using the same adaptor technique as in complex-reduction.c.

[DavidTruby]

I do not think the placement of #include <complex.h> matters. You will still have to include it for MSVC, and it is deprecated in C++17 as MSVC states.
You may try using the same adaptor technique as in complex-reduction.c.

Right, I've tried to move that adaptor here so that I could re-use it. But I think the #include <complex.h> needs to be inside the non-MSVC case and then we just use the MSVC builtins in that case.

flang/runtime/complex-powi.cpp

68

Should I also use int32_t as well? I guess so

[vzakhari]

In D134889#3824843, @DavidTruby wrote:

I do not think the placement of #include <complex.h> matters. You will still have to include it for MSVC, and it is deprecated in C++17 as MSVC states.
You may try using the same adaptor technique as in complex-reduction.c.

Right, I've tried to move that adaptor here so that I could re-use it. But I think the #include <complex.h> needs to be inside the non-MSVC case and then we just use the MSVC builtins in that case.

I guess you can try this.

flang/runtime/complex-powi.cpp

68

It should not matter int or int32_t, so it is up to you :)

[DavidTruby]

It looks like there's no way to get it working this way with MSVC, so I will have to change the file to C and not use a template for it. I will probably put the implementation inside a macro and instantiate that for the different types we have instead.

I'll need to do something about the GTEST tests still as those have to be written in C++. I'll probably expose a pointer interface from the C side for this and pass a pointer to a C++ complex in, as the types are at least layout compatible.

[vzakhari]

In D134889#3827036, @DavidTruby wrote:

It looks like there's no way to get it working this way with MSVC, so I will have to change the file to C and not use a template for it. I will probably put the implementation inside a macro and instantiate that for the different types we have instead.

I'll need to do something about the GTEST tests still as those have to be written in C++. I'll probably expose a pointer interface from the C side for this and pass a pointer to a C++ complex in, as the types are at least layout compatible.

I just want to point out that complex-reduction.c proposes a different solution that still allows using C++ templates for the actual implementation but requires defining C wrappers for interfacing with the compiler. I guess this way you might be able to use the Cpp names to directly invoke the C++ implementation methods with C++ complex data type. I know it is not testing exactly what the compiler generates, but at least you will not have to rely on the types layout compatibility.

[DavidTruby]

Doing it using C didn't work either, as MSVC doesn't support operators on complex
numbers in C.
I'm hopeful that after investigation what I've done here will work correctly, but
I haven't been able to test it on Windows so I'm uploading it to see if it passes
the pre-commit CI.

[DavidTruby]

Extra fixes for MSVC.
This is my last try before I set up a Windows dev environment for myself. Sorry for
the spam!

[klausler]

I agree that this is probably the best algorithm to use, rather than casting to a more general cpow or converting to/from polar coordinates. Thanks for working around MSVC's poor implementation of complex.

flang/include/flang/Runtime/entry-names.h

27

why is RTNAME_STRINGIFY_ needed? can't this just be #x?

flang/runtime/complex-powi.cpp

18

Don't bother with guesses about fast-path cases. The only one needed for correctness is 0 and that can be an if.

31

We use modern braced initialization in the runtime for safety. bool invertResult{exp < 0}; would be more clear.

33

This will fail when exp is the most negative value.

126

Please terminate the source file with a newline.

flang/unittests/Runtime/Complex.cpp

51

Braces, please.

146

Omit the lower-case letter "l" suffixes; they look like digits, they're not necessary, and they depend implicitly on long being 64 bits, which it isn't everywhere. If you must have explicit int64_t values, use static_cast<>.

[DavidTruby]

Use brace initialization for variables.
Handle case where exp == INT_MIN
Additional fixes for MSVC

[DavidTruby]

I don't think the linux failure here is down to my patch?
The MSVC one is; it seems cpowi and cpowk are passing but not zpowi or zpowk. I have no idea why, I don't have access to MSVC to check properly atm

[DavidTruby]

flang/include/flang/Runtime/entry-names.h

27

I tried it without and it doesn't expand to the right thing. I will be honest and admit I have no idea why :)

[vzakhari]

In D134889#3837303, @DavidTruby wrote:

I don't think the linux failure here is down to my patch?
The MSVC one is; it seems cpowi and cpowk are passing but not zpowi or zpowk. I have no idea why, I don't have access to MSVC to check properly atm

Hi David, I will try to reproduce it on Windows today and will let you know.

[DavidTruby]

Hi David, I will try to reproduce it on Windows today and will let you know.

That would be great, thanks! I'm trying to get a Windows setup that I can test it on but it's a slow process getting everything sorted... And I don't immediately understand the error message in the CI

[vzakhari]

flang/runtime/complex-powi.cpp

87

Can you please clarify where the documentation says that their _[FDL]complex implementation is necessarily using the structure representation?

I do not really like that we now have two potentially different ways of passing "complex" to the runtime functions (one here and another for complex reduction functions). I would rather have it uniform, so, for example, try to keep using float_Complex_t typedefs defined in complex-reduction.h

flang/unittests/Runtime/Complex.cpp

34

typo here and below: float -> double

This causes the test failure on Windows.

[DavidTruby]

flang/runtime/complex-powi.cpp

87

It's here in the docs:

The compiler doesn't directly support a complex or _Complex keyword, therefore the Microsoft implementation uses structure types to represent complex numbers.

I agree I'd rather use the stuff from complex-reduction.h and I tried that initially, but you cannot get _[FDL]complex in a C++ file without MSVC erroring out... This is the best way I found to work around those issues.

flang/unittests/Runtime/Complex.cpp

34

I assumed it would be a daft mistake. Thanks!

[DavidTruby]

flang/runtime/complex-powi.cpp

87

Another proposal: we could define float_Complex_t and double_Complex_t to be struct {float; float;} and struct {doule; double} instead of _Fcomplex and _Dcomplex ourselves in a shared header between this and complex-reduction.h, as those are just the definitions in MSVC.

[vzakhari]

flang/runtime/complex-powi.cpp

87

The compiler doesn't directly support a complex or _Complex keyword, therefore the Microsoft implementation uses structure types to represent complex numbers.

Thanks! I must be reading every other line :)

I agree I'd rather use the stuff from complex-reduction.h and I tried that initially, but you cannot get _[FDL]complex in a C++ file without MSVC erroring out... This is the best way I found to work around those issues.

Not sure what you mean by "the best way" :)
My point is that complex-reduction.c and complex-reduction.h already solve this exact problem, and they allow using C++ templates in sum.cpp for the actual implementation. I understand that this is a little bit more work, but we gain the uniformity, which seems important to me.

[DavidTruby]

flang/runtime/complex-powi.cpp

87

My point is that complex-reduction.c and complex-reduction.h already solve this exact problem, and they allow using C++ templates in sum.cpp for the actual implementation. I understand that this is a little bit more work, but we gain the uniformity, which seems important to me.

Sorry let me clarify; you can't include complex-reduction.h in a C++ file portably because you can't transitively include complex.h or ccomplex in MSVC without an error.
I tried to take the definitions of float_Complex_t and double_Complex_t from complex-reduction.h into a shared header, and this is the first issue I hit when trying to include it here.

Even if we rewrite this file itself in C and use macros for generating functions of all the correct types (which I think would be a lot more messy!) we still can't include the abstraction used in complex-reduction.h in the gtest file, because gtest only supports C++. So at some point we have to separately make the definition that Dcomplex and Fcomplex are {double; double} and {float; float} on Windows, whether that be in the implementation or the tests. Given this fact I'd rather keep the cleaner implementation without macros.

[vzakhari]

flang/runtime/complex-powi.cpp

87

Sorry, I forgot about the gtest. I suppose we can create wrappers in an extra C file inside flang/unittests/Runtime/: the wrappers will have struct {real; real;} arguments rather than complex and will also return struct {real; real;}, and the wrappers will call the runtime functions using proper C complex types by repacking their arguments and the return values from the runtime. Then in flang/unittests/Runtime/Complex.cpp we will just declare those wrappers as extern "C" functions without using any complex data types.

[DavidTruby]

flang/runtime/complex-powi.cpp

87

That could work but I don't feel that it buys us anything over just defining Dcomplex and Fcomplex ourselves and having a much neater implementation for the powi.

Since we know from the MSVC docs that Dcomplex is just {double; double} and Fcomplex is just {float; float}, I don't feel that there's any benefit using the MSVC definitions from the "poisonous" header than just writing our own definitions that are identical in both layout and ABI.

Essentially I'm reticent to make the general code for powi less readable, writeable and testable just to work around MSVC. I think we should do MSVC workarounds _for MSVC_ and not force them on every compiler.

[DavidTruby]

flang/runtime/complex-powi.cpp

87

Additionally, FWIW, because _Fcomplex and _Dcomplex really are just structs, they don't have any operators defined on them. So it's not even as simple as wrapping the tgpowi I've got here in a macro in a C file as that still won't work in MSVC. It would require entirely separate definitions for MSVC and non-MSVC as z * z is only available as a function in C in MSVC, not as an operator.

[klausler]

flang/runtime/complex-powi.cpp

87

Complex multiplication can just be written in terms of components, as can the division into (1.,0) for the reciprocal.

[DavidTruby]

flang/runtime/complex-powi.cpp

87

It can indeed. However, accessing the components is done differently in MSVC as for C complex numbers, so it'd still need a separate implementation (or macros every time you access re and im), and doing it this way would still make the code less clear and readable than it is right now.

My strong preference is for MSVC workarounds to be limited to MSVC branches and not litter the generic code.

[vzakhari]

Thank you, David. Let's keep it as it is right now.

[DavidTruby]

Fix MSVC wrapper bug

[vzakhari]

Thanks!

flang/include/flang/Runtime/entry-names.h

  * The value of REVISION should not be changed until/unless the API to the
  * runtime library must change in some way that breaks backward compatibility.
  */
 #ifndef RTNAME
 #define NAME_WITH_PREFIX_AND_REVISION(prefix, revision, name) \
   prefix##revision##name
 #define RTNAME(name) NAME_WITH_PREFIX_AND_REVISION(_Fortran, A, name)
 #endif
+
+#ifndef RTNAME_STRING
+#define RTNAME_STRINGIFY_(x) #x
+#define RTNAME_STRINGIFY(x) RTNAME_STRINGIFY_(x)
+#define RTNAME_STRING(name) RTNAME_STRINGIFY(RTNAME(name))
+#endif

flang/lib/Lower/IntrinsicCall.cpp

 #include "flang/Optimizer/Builder/Runtime/Numeric.h"
 #include "flang/Optimizer/Builder/Runtime/RTBuilder.h"
 #include "flang/Optimizer/Builder/Runtime/Reduction.h"
 #include "flang/Optimizer/Builder/Runtime/Stop.h"
 #include "flang/Optimizer/Builder/Runtime/Transformational.h"
 #include "flang/Optimizer/Builder/Todo.h"
 #include "flang/Optimizer/Dialect/FIROpsSupport.h"
 #include "flang/Optimizer/Support/FatalError.h"
+#include "flang/Runtime/entry-names.h"
 #include "mlir/Dialect/LLVMIR/LLVMDialect.h"
 #include "mlir/Dialect/Math/IR/Math.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Debug.h"
 
 #define DEBUG_TYPE "flang-lower-intrinsic"
 
 #define PGMATH_DECLARE

 }
 
 static mlir::FunctionType genF64ComplexFuncType(mlir::MLIRContext *context) {
   auto ctype = fir::ComplexType::get(context, 8);
   auto ftype = mlir::FloatType::getF64(context);
   return mlir::FunctionType::get(context, {ctype}, {ftype});
 }
 
+template <int Kind, int Bits>
+static mlir::FunctionType
+genComplexComplexIntFuncType(mlir::MLIRContext *context) {
+  auto ctype = fir::ComplexType::get(context, Kind);
+  auto itype = mlir::IntegerType::get(context, Bits);
+  return mlir::FunctionType::get(context, {ctype, itype}, {ctype});
+}
+
 /// Callback type for generating lowering for a math operation.
 using MathGeneratorTy = mlir::Value (*)(fir::FirOpBuilder &, mlir::Location,
                                         llvm::StringRef, mlir::FunctionType,
                                         llvm::ArrayRef<mlir::Value>);
 
 struct MathOperation {
   // llvm::StringRef comparison operator are not constexpr, so use string_view.
   using Key = std::string_view;
static constexpr MathOperation mathOperations[] = {
     {"pow", {}, genIntIntIntFuncType<64>, genMathOp<mlir::math::IPowIOp>},
     {"pow", "powf", genF32F32F32FuncType, genMathOp<mlir::math::PowFOp>},
     {"pow", "pow", genF64F64F64FuncType, genMathOp<mlir::math::PowFOp>},
     {"pow", "cpowf", genComplexComplexComplexFuncType<4>, genLibCall},
     {"pow", "cpow", genComplexComplexComplexFuncType<8>, genLibCall},
     // TODO: add PowIOp in math and complex dialects.
     {"pow", "llvm.powi.f32.i32", genF32F32IntFuncType<32>, genLibCall},
     {"pow", "llvm.powi.f64.i32", genF64F64IntFuncType<32>, genLibCall},
+    {"pow", RTNAME_STRING(cpowi), genComplexComplexIntFuncType<4, 32>,
+     genLibCall},
+    {"pow", RTNAME_STRING(zpowi), genComplexComplexIntFuncType<8, 32>,
+     genLibCall},
+    {"pow", RTNAME_STRING(cpowk), genComplexComplexIntFuncType<4, 64>,
+     genLibCall},
+    {"pow", RTNAME_STRING(zpowk), genComplexComplexIntFuncType<8, 64>,
+     genLibCall},
     {"sign", "copysignf", genF32F32F32FuncType,
      genMathOp<mlir::math::CopySignOp>},
     {"sign", "copysign", genF64F64F64FuncType,
      genMathOp<mlir::math::CopySignOp>},
     {"sign", "copysignl", genF80F80F80FuncType,
      genMathOp<mlir::math::CopySignOp>},
     {"sign", "llvm.copysign.f128", genF128F128F128FuncType,
      genMathOp<mlir::math::CopySignOp>},

flang/lib/Optimizer/Transforms/SimplifyIntrinsics.cpp

 #include "llvm/Support/Debug.h"
 #include "llvm/Support/raw_ostream.h"
 
 namespace fir {
 #define GEN_PASS_DEF_SIMPLIFYINTRINSICS
 #include "flang/Optimizer/Transforms/Passes.h.inc"
 } // namespace fir
 
-#define RTNAME_STRINGIFY2(x) #x
-#define RTNAME_STRINGIFY(x) RTNAME_STRINGIFY2(x)
-#define RTNAME_STRING(x) RTNAME_STRINGIFY(RTNAME(x))
-
 #define DEBUG_TYPE "flang-simplify-intrinsics"
 
 namespace {
 
 class SimplifyIntrinsicsPass
     : public fir::impl::SimplifyIntrinsicsBase<SimplifyIntrinsicsPass> {
   using FunctionTypeGeneratorTy =
       llvm::function_ref<mlir::FunctionType(fir::FirOpBuilder &)>;

flang/runtime/CMakeLists.txt

 add_subdirectory(FortranMain)
 
 add_flang_library(FortranRuntime
   ISO_Fortran_binding.cpp
   allocatable.cpp
   assign.cpp
   buffer.cpp
   command.cpp
+  complex-powi.cpp
   complex-reduction.c
   copy.cpp
   character.cpp
   connection.cpp
   derived.cpp
   derived-api.cpp
   descriptor.cpp
   descriptor-io.cpp

flang/runtime/complex-powi.cpp

+/*===-- flang/runtime/complex-powi.cpp ----------------------------*- C++ -*-===
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+ * ===-----------------------------------------------------------------------===
+ */
+#include "flang/Runtime/entry-names.h"
+#include <cstdint>
+#include <cstdio>
+#include <limits>
+
+#ifdef __clang_major__
+#pragma clang diagnostic ignored "-Wc99-extensions"
+#endif
+
+template <typename C, typename I> C tgpowi(C base, I exp) {
+  if (exp == 0) {
+    return C{1};
+  }
+
+  bool invertResult{exp < 0};
+  bool isMin{exp == std::numeric_limits<I>::min()};
+
+  if (isMin) {
+    exp = std::numeric_limits<I>::max();
+  }
+
+  if (exp < 0) {
+    exp = exp * -1;
+  }
+
+  C origBase{base};
+
+  while ((exp & 1) == 0) {
+    base *= base;
+    exp >>= 1;
+  }
+
+  C acc{base};
+
+  while (exp > 1) {
+    exp >>= 1;
+    base *= base;
+    if ((exp & 1) == 1) {
+      acc *= base;
+    }
+  }
+
+  if (isMin) {
+    acc *= origBase;
+  }
+
+  if (invertResult) {
+    acc = C{1} / acc;
+  }
+
+  return acc;
+}
+
+#ifndef _MSC_VER
+// With most compilers, C complex is implemented as a builtin type that may have
+// specific ABI requirements
+extern "C" float _Complex RTNAME(cpowi)(float _Complex base, std::int32_t exp) {
+  return tgpowi(base, exp);
+}
+
+extern "C" double _Complex RTNAME(zpowi)(
+    double _Complex base, std::int32_t exp) {
+  return tgpowi(base, exp);
+}
+
+extern "C" float _Complex RTNAME(cpowk)(float _Complex base, std::int64_t exp) {
+  return tgpowi(base, exp);
+}
+
+extern "C" double _Complex RTNAME(zpowk)(
+    double _Complex base, std::int64_t exp) {
+  return tgpowi(base, exp);
+}
+#else
+// on MSVC, C complex is always just a struct of two members as it is not
+// supported as a builtin type. So we use C++ complex here as that has the
+// same ABI and layout. See:
+// https://learn.microsoft.com/en-us/cpp/c-runtime-library/complex-math-support
+#include <complex>
+
+// MSVC doesn't allow including <ccomplex> or <complex.h> in C++17 mode to get
+// the Windows definitions of these structs so just redefine here.
+struct Fcomplex {
+  float re;
+  float im;
+};
+
+struct Dcomplex {
+  double re;
+  double im;
+};
+
+extern "C" Fcomplex RTNAME(cpowi)(Fcomplex base, std::int32_t exp) {
+  auto cppbase = *(std::complex<float> *)(&base);
+  auto cppres = tgpowi(cppbase, exp);
+  return *(Fcomplex *)(&cppres);
+}
+
+extern "C" Dcomplex RTNAME(zpowi)(Dcomplex base, std::int32_t exp) {
+  auto cppbase = *(std::complex<double> *)(&base);
+  auto cppres = tgpowi(cppbase, exp);
+  return *(Dcomplex *)(&cppres);
+}
+
+extern "C" Fcomplex RTNAME(cpowk)(Fcomplex base, std::int64_t exp) {
+  auto cppbase = *(std::complex<float> *)(&base);
+  auto cppres = tgpowi(cppbase, exp);
+  return *(Fcomplex *)(&cppres);
+}
+
+extern "C" Dcomplex RTNAME(zpowk)(Dcomplex base, std::int32_t exp) {
+  auto cppbase = *(std::complex<double> *)(&base);
+  auto cppres = tgpowi(cppbase, exp);
+  return *(Dcomplex *)(&cppres);
+}
+
+#endif

flang/test/Lower/power-operator.f90

subroutine pow_i8_i8(x, y, z)
   ! CHECK: math.ipowi %{{.*}}, %{{.*}} : i64
 end subroutine
 
 ! CHECK-LABEL: pow_c4_i4
 subroutine pow_c4_i4(x, y, z)
   complex :: x, z
   integer :: y
   z = x ** y
-  ! CHECK: call @__fc_powi_1
+  ! CHECK: call @_FortranAcpowi
 end subroutine
 
 ! CHECK-LABEL: pow_c4_i8
 subroutine pow_c4_i8(x, y, z)
   complex :: x, z
   integer(8) :: y
   z = x ** y
-  ! CHECK: call @__fc_powk_1
+  ! CHECK: call @_FortranAcpowk
 end subroutine
 
 ! CHECK-LABEL: pow_c8_i4
 subroutine pow_c8_i4(x, y, z)
   complex(8) :: x, z
   integer :: y
   z = x ** y
-  ! CHECK: call @__fz_powi_1
+  ! CHECK: call @_FortranAzpowi
 end subroutine
 
 ! CHECK-LABEL: pow_c8_i8
 subroutine pow_c8_i8(x, y, z)
   complex(8) :: x, z
   integer(8) :: y
   z = x ** y
-  ! CHECK: call @__fz_powk_1
+  ! CHECK: call @_FortranAzpowk
 end subroutine
 
 ! CHECK-LABEL: pow_c4_c4
 subroutine pow_c4_c4(x, y, z)
   complex :: x, y, z
   z = x ** y
   ! CHECK: call @cpowf
 end subroutine
 
 ! CHECK-LABEL: pow_c8_c8
 subroutine pow_c8_c8(x, y, z)
   complex(8) :: x, y, z
   z = x ** y
   ! CHECK: call @cpow
 end subroutine
 

flang/unittests/Runtime/CMakeLists.txt

 add_flang_unittest(FlangRuntimeTests
   BufferTest.cpp
   CharacterTest.cpp
   CommandTest.cpp
+  Complex.cpp
   CrashHandlerFixture.cpp
   ExternalIOTest.cpp
   Format.cpp
   Inquiry.cpp
   ListInputTest.cpp
   Matmul.cpp
   MiscIntrinsic.cpp
   Namelist.cpp

flang/unittests/Runtime/Complex.cpp

+//===-- flang/unittests/Runtime/Complex.cpp ---------------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+#include "gmock/gmock.h"
+#include "gtest/gtest-matchers.h"
+#include <limits>
+
+#ifdef __clang__
+#pragma clang diagnostic ignored "-Wc99-extensions"
+#endif
+
+#include "flang/Common/Fortran.h"
+#include "flang/Runtime/cpp-type.h"
+#include "flang/Runtime/entry-names.h"
+
+#include <complex>
+#include <cstdint>
+
+#ifndef _MSC_VER
+#include <complex.h>
+typedef float _Complex float_Complex_t;
+typedef double _Complex double_Complex_t;
+#else
+struct float_Complex_t {
+  float re;
+  float im;
+};
+struct double_Complex_t {
+  double re;
+  double im;
+};
+#endif
+
+extern "C" float_Complex_t RTNAME(cpowi)(
+    float_Complex_t base, std::int32_t exp);
+
+extern "C" double_Complex_t RTNAME(zpowi)(
+    double_Complex_t base, std::int32_t exp);
+
+extern "C" float_Complex_t RTNAME(cpowk)(
+    float_Complex_t base, std::int64_t exp);
+
+extern "C" double_Complex_t RTNAME(zpowk)(
+    double_Complex_t base, std::int64_t exp);
+
+static std::complex<float> cpowi(std::complex<float> base, std::int32_t exp) {
+  float_Complex_t cbase{*(float_Complex_t *)(&base)};
+  float_Complex_t cres{RTNAME(cpowi)(cbase, exp)};
+  return *(std::complex<float> *)(&cres);
+}
+
+static std::complex<double> zpowi(std::complex<double> base, std::int32_t exp) {
+  double_Complex_t cbase{*(double_Complex_t *)(&base)};
+  double_Complex_t cres{RTNAME(zpowi)(cbase, exp)};
+  return *(std::complex<double> *)(&cres);
+}
+
+static std::complex<float> cpowk(std::complex<float> base, std::int64_t exp) {
+  float_Complex_t cbase{*(float_Complex_t *)(&base)};
+  float_Complex_t cres{RTNAME(cpowk)(cbase, exp)};
+  return *(std::complex<float> *)(&cres);
+}
+
+static std::complex<double> zpowk(std::complex<double> base, std::int64_t exp) {
+  double_Complex_t cbase{*(double_Complex_t *)(&base)};
+  double_Complex_t cres{RTNAME(zpowk)(cbase, exp)};
+  return *(std::complex<double> *)(&cres);
+}
+
+MATCHER_P(ExpectComplexFloatEq, c, "") {
+  using namespace testing;
+  return ExplainMatchResult(
+      AllOf(Property(&std::complex<float>::real, FloatEq(c.real())),
+          Property(&std::complex<float>::imag, FloatEq(c.imag()))),
+      arg, result_listener);
+}
+
+MATCHER_P(ExpectComplexDoubleEq, c, "") {
+  using namespace testing;
+  return ExplainMatchResult(AllOf(Property(&std::complex<double>::real,
+                                      DoubleNear(c.real(), 0.00000001)),
+                                Property(&std::complex<double>::imag,
+                                    DoubleNear(c.imag(), 0.00000001))),
+      arg, result_listener);
+}
+
+#define EXPECT_COMPLEX_FLOAT_EQ(val1, val2) \
+  EXPECT_THAT(val1, ExpectComplexFloatEq(val2))
+
+#define EXPECT_COMPLEX_DOUBLE_EQ(val1, val2) \
+  EXPECT_THAT(val1, ExpectComplexDoubleEq(val2))
+
+using namespace std::literals::complex_literals;
+
+TEST(Complex, cpowi) {
+  EXPECT_COMPLEX_FLOAT_EQ(cpowi(3.f + 4if, 0), 1.f + 0if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowi(3.f + 4if, 1), 3.f + 4if);
+
+  EXPECT_COMPLEX_FLOAT_EQ(cpowi(3.f + 4if, 2), -7.f + 24if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowi(3.f + 4if, 3), -117.f + 44if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowi(3.f + 4if, 4), -527.f - 336if);
+
+  EXPECT_COMPLEX_FLOAT_EQ(cpowi(3.f + 4if, -2), -0.0112f - 0.0384if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowi(2.f + 1if, 10), -237.f - 3116if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowi(0.5f + 0.6if, -10), -9.322937f - 7.2984829if);
+
+  EXPECT_COMPLEX_FLOAT_EQ(cpowi(2.f + 1if, 5), -38.f + 41if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowi(0.5f + 0.6if, -5), -1.121837f + 3.252915if);
+
+  EXPECT_COMPLEX_FLOAT_EQ(
+      cpowi(0.f + 1if, std::numeric_limits<std::int32_t>::min()), 1.f + 0if);
+}
+
+TEST(Complex, cpowk) {
+  EXPECT_COMPLEX_FLOAT_EQ(cpowk(3.f + 4if, 0), 1.f + 0if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowk(3.f + 4if, 1), 3.f + 4if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowk(3.f + 4if, 2), -7.f + 24if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowk(3.f + 4if, 3), -117.f + 44if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowk(3.f + 4if, 4), -527.f - 336if);
+
+  EXPECT_COMPLEX_FLOAT_EQ(cpowk(3.f + 4if, -2), -0.0112f - 0.0384if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowk(2.f + 1if, 10), -237.f - 3116if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowk(0.5f + 0.6if, -10), -9.322937f - 7.2984829if);
+
+  EXPECT_COMPLEX_FLOAT_EQ(cpowk(2.f + 1if, 5), -38.f + 41if);
+  EXPECT_COMPLEX_FLOAT_EQ(cpowk(0.5f + 0.6if, -5), -1.121837f + 3.252915if);
+
+  EXPECT_COMPLEX_FLOAT_EQ(
+      cpowk(0.f + 1if, std::numeric_limits<std::int64_t>::min()), 1.f + 0if);
+}
+
+TEST(Complex, zpowi) {
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowi(3. + 4i, 0), 1. + 0i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowi(3. + 4i, 1), 3. + 4i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowi(3. + 4i, 2), -7. + 24i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowi(3. + 4i, 3), -117. + 44i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowi(3. + 4i, 4), -527. - 336i);
+
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowi(3. + 4i, -2), -0.0112 - 0.0384i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowi(2. + 1i, 10), -237. - 3116i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowi(0.5 + 0.6i, -10), -9.32293628 - 7.29848564i);
+
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowi(2. + 1i, 5), -38. + 41i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowi(0.5 + 0.6i, -5), -1.12183773 + 3.25291503i);
+
+  EXPECT_COMPLEX_DOUBLE_EQ(
+      zpowi(0. + 1i, std::numeric_limits<std::int32_t>::min()), 1. + 0i);
+}
+
+TEST(Complex, zpowk) {
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowk(3. + 4i, 0), 1. + 0i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowk(3. + 4i, 1), 3. + 4i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowk(3. + 4i, 2), -7. + 24i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowk(3. + 4i, 3), -117. + 44i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowk(3. + 4i, 4), -527. - 336i);
+
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowk(3. + 4i, -2), -0.0112 - 0.0384i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowk(2. + 1i, 10), -237. - 3116i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowk(0.5 + 0.6i, -10), -9.32293628 - 7.29848564i);
+
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowk(2. + 1i, 5l), -38. + 41i);
+  EXPECT_COMPLEX_DOUBLE_EQ(zpowk(0.5 + 0.6i, -5), -1.12183773 + 3.25291503i);
+
+  EXPECT_COMPLEX_DOUBLE_EQ(
+      zpowk(0. + 1i, std::numeric_limits<std::int64_t>::min()), 1. + 0i);
+}