From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12497 invoked by alias); 29 Sep 2009 20:23:53 -0000 Received: (qmail 12460 invoked by uid 22791); 29 Sep 2009 20:23:52 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e36.co.us.ibm.com (HELO e36.co.us.ibm.com) (32.97.110.154) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Sep 2009 20:23:47 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8TKLk6n000701; Tue, 29 Sep 2009 14:21:46 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8TKNbiu032886; Tue, 29 Sep 2009 14:23:37 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8TKNarq011426; Tue, 29 Sep 2009 14:23:37 -0600 Received: from [9.47.18.91] (dyn9047018091.beaverton.ibm.com [9.47.18.91]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8TKNUKS011166; Tue, 29 Sep 2009 14:23:33 -0600 Subject: Re: C++ support for decimal floating point From: Janis Johnson Reply-To: janis187@us.ibm.com To: Gabriel Dos Reis Cc: Richard Guenther , gcc@gcc.gnu.org, libstdc++@gcc.gnu.org In-Reply-To: <206fcf960909231639s47123c2dqaa21d9493e79d995@mail.gmail.com> References: <1253666313.6130.8.camel@janis-laptop> <84fc9c000909230129w167878ccn2b3402b7305d1366@mail.gmail.com> <1253740316.5999.6.camel@janis-laptop> <206fcf960909231427t33830d1cu15402a72acbb4159@mail.gmail.com> <1253748187.5999.12.camel@janis-laptop> <206fcf960909231639s47123c2dqaa21d9493e79d995@mail.gmail.com> Content-Type: text/plain Date: Tue, 29 Sep 2009 20:37:00 -0000 Message-Id: <1254255810.6078.26.camel@janis-laptop> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00615.txt.bz2 On Wed, 2009-09-23 at 18:39 -0500, Gabriel Dos Reis wrote: > On Wed, Sep 23, 2009 at 6:23 PM, Janis Johnson wrote: > > On Wed, 2009-09-23 at 16:27 -0500, Gabriel Dos Reis wrote: > >> On Wed, Sep 23, 2009 at 4:11 PM, Janis Johnson wrote: > >> > On Wed, 2009-09-23 at 10:29 +0200, Richard Guenther wrote: > >> >> On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson wrote: > >> >> > I've been implementing ISO/IEC TR 24733, "an extension for the > >> >> > programming language C++ to support decimal floating-point arithmetic", > >> >> > in GCC. It might be ready as an experimental feature for 4.5, but I > >> >> > would particularly like to get in the compiler changes that are needed > >> >> > for it. > >> >> > > >> >> > Most of the support for the TR is in new header files in libstdc++ that > >> >> > depend on compiler support for decimal float scalar types. Most of that > >> >> > compiler functionality was already available in G++ via mode attributes. > >> >> > I've made a couple of small fixes and have a couple more to submit, and > >> >> > when those are in I'll starting running dfp tests for C++ as well as C. > >> >> > The suitable tests have already been moved from gcc.dg to c-c++-common. > >> >> > > >> >> > In order to provide interoperability with C, people on the C++ ABI > >> >> > mailing list suggested that a C++ compiler should recognize the new > >> >> > decimal classes defined in the TR and pass arguments of those types the > >> >> > same as scalar decimal float types for a particular target. I had this > >> >> > working in an ugly way using a langhook, but that broke with LTO. I'm > >> >> > looking for the right places to record that an argument or return value > >> >> > should be passed as if it were a different type, but could use some > >> >> > advice about that. > >> >> > >> >> How do we (do we?) handle std::complex<> there? My first shot would > >> >> be to make sure the aggregate type has the proper mode, but I guess > >> >> most target ABIs would already pass them in registers, no? > >> > > >> > std::complex<> is not interoperable with GCC's complex extension, which > >> > is generally viewed as "unfortunate". > >> > >> Could you expand on why std::complex<> is not interoperable with GCC's > >> complex extension. The reason is that I would like to know better where > >> the incompatibilities come from -- I've tried to remove any. > > > > I was just repeating what I had heard from C++ experts. On > > powerpc-linux they are currently passed and mangled differently. > > I've been careful not to define a copy constructor or a destructor > for the specializations of std::complex so that they get treated as PODs, > with the hope that the compiler will do the right thing. At least on > my x86-64 box > running openSUSE, I don't see a difference. I've also left the > copy-n-assignment operator at the discretion of the compiler > > // The compiler knows how to do this efficiently > // complex& operator=(const complex&); > > So, if there is any difference on powerpc-*-linux, then that should be blamed on > poor ABI choice than anything else intrinsic to std::complex (or C++). > Where possible, we should look into how to fix that. > > In many ways, it is assumed that std::complex is isomorphic to the > GNU extension. The PowerPC 32-bit ELF ABI says that a struct is passed as a pointer to an object or a copy of the object. Classes are treated the same as classes. Does the C++ ABI have rules about classes like std::complex that would cause them to be treated differently? Janis