The "float complex" and "double complex" in nameToC need to be __complex instead. Not sure about dwarfToName. Also probably the first case in the switch at line 1692 should check for dwarf.ComplexType as well.

Looks like the DWARF names are "complex float" and "complex double" for both GCC and Clang, so the space stripping logic will map them to C.complexfloat and C.complexdouble even without any dwarfToName entries.

Hm, fixing this leads to:

./issue8694.go:27: cannot use x (type complex64) as type C.complexfloat in argument to _Cfunc_complexFloatSquared
./issue8694.go:28: invalid operation: cx2 != x2 (mismatched types C.complexfloat and complex64)
./issue8694.go:34: cannot use y (type complex128) as type C.complexdouble in argument to _Cfunc_complexDoubleSquared
./issue8694.go:35: invalid operation: cy2 != y2 (mismatched types C.complexdouble and complex128)

Apparently the status quo is cgo treats C.complexfloat and complex64 as equivalent (and similarly for C.complexdouble and complex128). Should we be worried that fixing this issue could break Go code that relies on this (seemingly erroneous) behavior?

CL https://golang.org/cl/17208 mentions this issue.

It does seem like people should need an explicit type conversion to the C type, so I think it's OK to make this change. Even if this were covered by the Go 1 guarantee, it is a bug fix.