From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9204 invoked by alias); 13 Dec 2007 22:25:17 -0000 Received: (qmail 9192 invoked by uid 22791); 13 Dec 2007 22:25:15 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Dec 2007 22:25:10 +0000 Received: (qmail 21334 invoked from network); 13 Dec 2007 22:25:08 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 13 Dec 2007 22:25:08 -0000 To: ""Doug Kwan (=?utf-8?B?6Zec5oyv5b63?=)"" Cc: "Mark Mitchell" , "Kenneth Zadeck" , "Andrew Pinski" , gcc-patches@gcc.gnu.org, "Diego Novillo" , "Nathan Froyd" Subject: Re: [LTO][PATCH] Fix long double precision problem References: <498552560712042305h6aa6f4d8jfdc8e9031b522604@mail.gmail.com> <47569FA0.5040308@naturalbridge.com> <4756D2FB.6020703@codesourcery.com> <498552560712051100s283acdc3le82c21759d7c3b6f@mail.gmail.com> <475739AD.5050705@codesourcery.com> <498552560712111504y77964103i3a0ad3743b77a5c9@mail.gmail.com> <475F55E4.1090203@codesourcery.com> <498552560712121127t76e5b0b9m52fd364b33d7d7c3@mail.gmail.com> <476047B6.3090704@codesourcery.com> <498552560712131231k785883e7mfb40b1636008a51b@mail.gmail.com> From: Jim Blandy Date: Thu, 13 Dec 2007 22:43:00 -0000 In-Reply-To: <498552560712131231k785883e7mfb40b1636008a51b@mail.gmail.com> (Doug Kwan's message of "Thu, 13 Dec 2007 12:31:47 -0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00634.txt.bz2 ""Doug Kwan (=E9=97=9C=E6=8C=AF=E5=BE=B7)"" writes: > What about complex long double? There are padding bits between the > real and imaginary parts. My understanding is that the base types are not meant to completely specify how the debugger should interpret a type it's never seen before; they're just meant to distinguish the source language's base types. For example, DWARF just has DW_ATE_float, not DW_ATE_ieee_float, nor DW_ATE_float with DW_AT_mantissa_bits and DW_AT_exponent_bias. Once the DWARF has identified the type, it's up to the ABI to specify the details of its representation. Under that interpretation, all GCC should do for long double complex is emit a DW_TAG_base_type with DW_ATE_complex_float and DW_AT_byte_size =3D=3D 24. That's enough to distinguish long double complex from double complex or float complex. It's not necessary for the DWARF to explicitly mention the 80-bit length if the ABI dictates that for a lone 24-byte complex type. (Do you also have a full 12-byte floating point complex format that would be ambiguous with that?) But that interpretation doesn't square too well with providing data like DW_AT_bit_size and DW_AT_bit_offset. So the interpretation is unclear to me. I don't remember this coming up; it may simply not have been considered.