[Bug target/86324] testsuite test divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86324

--- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> ---
And a complementary bug for a __ibm128 complex type when using
-mabi=ibmlongdouble:

bergner@pike:~/gcc/BUGS/PR86324$ cat divic.i 
typedef __complex float __cfloat128 __attribute__((mode(IC)));
__cfloat128
divide (__cfloat128 x, __cfloat128 y)
{
  return x / y;
}
bergner@pike:~/gcc/BUGS/PR86324$
/home/bergner/gcc/build/gcc-fsf-mainline-pr86324-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr86324-debug/gcc -S -O2 divic.i
-mabi=ibmlongdouble 
divic.i:1:1: error: no data type for mode ‘IC’
 typedef __complex float __cfloat128 __attribute__((mode(IC)));
 ^~~~~~~

The problem seems to be when long double is set to __ieee128, then
lang_hooks.types.type_for_mode() (ie, c_common_type_for_mode()) returns NULL
for the associated complex mode KCmode, but we return a valid tree type for
ICmode.  Vice versa, do long double equal to __ibm128, we return NULL for
ICmode, but we return a valid tree type for KCmode.

My guess is we're missing some initialization for the complex version of the
type that happens to be the same as long double.  In those cases,
rs6000_init_builtins() does:

  {ibm,ieee}128_float_type_node = long_double_type_node;

Maybe we need to have something like:

  complex_{ibm,ieee}128_float_type_node = complex_long_double_type_node;

???  Thoughts anyone?