From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15995 invoked by alias); 12 Dec 2002 19:56:06 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 15979 invoked by uid 71); 12 Dec 2002 19:56:05 -0000 Date: Thu, 12 Dec 2002 11:56:00 -0000 Message-ID: <20021212195605.15977.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Daniel Jacobowitz Subject: Re: debug/1621: Debugging with complex numbers Reply-To: Daniel Jacobowitz X-SW-Source: 2002-12/txt/msg00721.txt.bz2 List-Id: The following reply was made to PR debug/1621; it has been noted by GNATS. From: Daniel Jacobowitz To: Jim Wilson Cc: Wolfgang Bangerth , "Joseph S. Myers" , bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: debug/1621: Debugging with complex numbers Date: Thu, 12 Dec 2002 14:51:56 -0500 On Thu, Dec 12, 2002 at 10:55:17AM -0500, Jim Wilson wrote: > >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. Right. GDB already has a different mechanism to handle this case, so I'm not terribly worried about the details of using stabs and IEEE long double on a non-IEEE platform in this circumstance. > >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. Didn't you generate some 'R' entires for REAL_TYPE in the previous patch? > 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. Thank you! -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer