> The patch adds usage of "_Complex" to libgccjit.h.  ... "C99 or later"
> preprocessor guard. ... Also, this needs to be includeable from C++; I'm not sure what the
> precise requirements there are.

I did some thinking and I think it is impossible to mix std::complex and _Complex in the
same entry point. I did split up the _Complex parameters in the entrypoints to one real
and one imaginary part instead. That way is standard agnostic too.

+ gcc_jit_context_new_rvalue_from_complex_double (gcc_jit_context *ctxt,
+                                                 gcc_jit_type *numeric_type,
+                                                 double real, double imag)

> so presumably it should also guard
> gcc_jit_context_new_binary_op with op == GCC_JIT_BINARY_OP_COMPLEX.

+  if (op == GCC_JIT_BINARY_OP_COMPLEX)
+    {
+      RETURN_NULL_IF_FAIL (
+	ctxt->get_inner_bool_option (gcc::jit::INNER_BOOL_OPTION_ENABLE_COMPLEX_TYPES),
+	ctxt, NULL,
+	"the complex operator is only available after enabling it with"
+	" gcc_jit_context_set_bool_enable_complex_types()");

> though I'm
> nervous about all the tests that are comparing floating point values
> for equality; do we always get the precise expected value, on every
> target?  Floating point equality comparisons tend to be a nightmare in
> unit tests.

+     CHECK (cabs (ref - ans) < 0.0001);

+       CHECK_DOUBLE_VALUE (creal (ans), creal (key));
+       CHECK_DOUBLE_VALUE (cimag (ans), cimag (key));

I changed the comparisons that involve csqrt() and cpow () to be range checks instead.
I guess libgccjit and the test exe could maybe end up with different math-libs or something
and those are approximations. Also I removed the bytewise long double nan compare since I
realized the padding bytes changed when the optimization level is set to non-zero, and I
think getting the non-padding bytes might be hard in a platform independent way.

I think that the constant folds in the test exe and the compilation in libgccjit should
always end up with the same bit exact floating point number. Otherwise the host is really
strange and the user is probably happy to know that the calculations might differ. Like,
the operation order is the same and there should be no associativity errors (unless I messed
up the order in the key result and the libgccjit compilation).

Some old Intel processors with use the x87 FPU didn't adhere to IEEE floating point behavior, and
constant folding and runtime calculations would lead to different results on those. I have run
make check-jit in a 32 bit Debian VM though, so I think I got the tests right with that in mind.

E.g.:

#include <stdio.h>

main ()
{
     volatile double pi = 3.1416;
     double foo = pi * 6.28;

     double pi2 = 3.1416;
     double foo2 = pi2 * 6.28;

     printf ("Runtime: %g, ", foo - 3.1416 * 6.28);
     printf ("%d ", foo == 3.1416 * 6.28);
     printf ("Folded: %g, ", foo2 - 3.1416 * 6.28);
     printf ("%d\n", foo2 == 3.1416 * 6.28);

     // -m32 -mfpmath=387 -O0 => Runtime: 0, 1 Folded: 0, 1
     // -m32 -mfpmath=387 -O2 => Runtime: -1.43982e-15, 1 Folded: 0, 1
     // -m32 -mfpmath=sse -O2 => Runtime: 0, 1 Folded: 0, 1
}