gdb: Fix failure in gdb.base/complex-parts.exp for x86-32

The x86-32 ABI specifies 96-bit long double, this was causing a
failure on the test gdb.base/complex-parts.exp.

The problem is that GDB tries to find a builtin floating point type of
the correct size in order to reuse the name of that type as the name
for the components of the complex type being built.

Previously GDB was only aware of floating point types sized 32, 64, or
128 bits.  This patch teaches GDB how to handle 96 bit floating point
type.

gdb/ChangeLog:

	* dwarf2read.c (dwarf2_init_complex_target_type): Handle complex
	target types of size 96-bits, add some additional comments, and
	check that the builtin type we found was the correct size.

1 files changed, 10 insertions, 0 deletions

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index b718192..0873028 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -17546,6 +17546,9 @@ dwarf2_init_complex_target_type (struct dwarf2_cu *cu,
   gdbarch *gdbarch = get_objfile_arch (objfile);
   struct type *tt = nullptr;
 
+  /* Try to find a suitable floating point builtin type of size BITS.
+     We're going to use the name of this type as the name for the complex
+     target type that we are about to create.  */
   switch (bits)
     {
     case 32:
@@ -17554,11 +17557,18 @@ dwarf2_init_complex_target_type (struct dwarf2_cu *cu,
     case 64:
       tt = builtin_type (gdbarch)->builtin_double;
       break;
+    case 96:	/* The x86-32 ABI specifies 96-bit long double.  */
     case 128:
       tt = builtin_type (gdbarch)->builtin_long_double;
       break;
     }
 
+  /* If the type we found doesn't match the size we were looking for, then
+     pretend we didn't find a type at all, the complex target type we
+     create will then be nameless.  */
+  if (TYPE_LENGTH (tt) * TARGET_CHAR_BIT != bits)
+    tt = nullptr;
+
   const char *name = (tt == nullptr) ? nullptr : TYPE_NAME (tt);
   return dwarf2_init_float_type (objfile, bits, name, name_hint);
 }