Re: debug/1621: Debugging with complex numbers

[Jim Wilson <wilson@redhat.com>]

The following reply was made to PR debug/1621; it has been noted by GNATS.

From: Jim Wilson <wilson@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Wolfgang Bangerth <bangerth@ticam.utexas.edu>,
   "Joseph S. Myers" <jsm28@cam.ac.uk>, bangerth@dealii.org,
   gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: debug/1621: Debugging with complex numbers
Date: 12 Dec 2002 10:55:17 -0500

 >I recommend emitting just the generic NF_COMPLEX and NF_FLOATING (?)
 >for any of the unknown types.
 
 NF_COMPLEX is supposed to be IEEE single complex.  There is no generic
 value for complex types.  However, I do see your point, since we have the
 type size anyways, we don't really need to distinguish between the different
 complex types for IEEE FP targets.
 
 There is a problem if we want to distinguish between IEEE and non-IEEE FP,
 in which case the type size is not enough.  For instance, most RISC targets
 use a 128-bit IEEE double-extended type.  However, some powerpc targets use
 a 128-bit non-IEEE IBM pair-of-doubles type.  We can distinguish between these
 two only if we have a special NF_* value for the IBM pair-of-doubles type.
 Or alternatively, gdb just has to know that some targets use a non-IEEE long
 double type.  This is different problem from the one we are trying to fix
 though, and can be postponed for now.
 
 >First of all, for floating point types we could just continue to use
 >'r'.  It's not problematic in that case.  On the other hand consistency
 >is nice.
 
 My patch continues to use 'r' for floating point types for now.  I didn't
 want to break backwards compatibility for other stabs targets.  'R' will
 presumably only work on the Sun debugger and gdb.  It is OK to use 'R' for
 complex because it is an GNU C extension to ISO C90, so users can't expect
 old debuggers to handle it correctly.
 
 I will modify my patch to use NF_COMPLEX and NF_SINGLE as generic FP type
 descriptors and add appropriate comments about what we are doing in order
 to fix GCC PR debug/1621.
 
 Jim