From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12901 invoked by alias); 24 Feb 2014 10:34:18 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 12892 invoked by uid 89); 24 Feb 2014 10:34:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp18.uk.ibm.com Received: from e06smtp18.uk.ibm.com (HELO e06smtp18.uk.ibm.com) (195.75.94.114) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 24 Feb 2014 10:34:16 +0000 Received: from /spool/local by e06smtp18.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 24 Feb 2014 10:34:13 -0000 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp18.uk.ibm.com (192.168.101.148) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 24 Feb 2014 10:34:11 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 52CBE17D8063 for ; Mon, 24 Feb 2014 10:34:43 +0000 (GMT) Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps4075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s1OAXxvR63373470 for ; Mon, 24 Feb 2014 10:33:59 GMT Received: from d06av11.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s1OAYAHi029488 for ; Mon, 24 Feb 2014 03:34:10 -0700 Received: from bl3ahm9f.de.ibm.com (dyn-9-152-212-203.boeblingen.de.ibm.com [9.152.212.203]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s1OAYAdQ029482 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Feb 2014 03:34:10 -0700 Received: from dvogt by bl3ahm9f.de.ibm.com with local (Exim 4.76) (envelope-from ) id 1WHsrT-0001MC-IT; Mon, 24 Feb 2014 11:34:11 +0100 Date: Mon, 24 Feb 2014 10:34:00 -0000 From: Dominik Vogt To: libffi-discuss@sourceware.org Cc: Andreas Krebbel , Ulrich Weigand , Andreas Arnez Subject: C99 complex types support Message-ID: <20140224103411.GA5130@linux.vnet.ibm.com> Reply-To: vogt@linux.vnet.ibm.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14022410-6892-0000-0000-000007EA2F69 X-IsSubscribed: yes X-SW-Source: 2014/txt/msg00005.txt.bz2 I'm thinking about implementing support for complex types in libffi. At the moment some implementations that use libffi emulate complex types as structs with two fields, but this does not work on all targets. Specifically, s390 and s390x are unable to handle "_Complex float" as structs (or the complex64 type in the Go language). In 2007 there was a short discussion about complex: > > Tom Tromey schrieb: > > >>>>>> "Thomas" == Thomas Heller writes: > > I would possibly be able to find the official specification how > > complex types have to be passed for architectures that I have access to > > AND I'm at least halfway familiar with (x86 and AMD64, maybe G4), but there > > is no hope I could make a patch for other architectures. How would that > > be handled? > > Offhand I don't know. I guess we could make it an error on > unsupported platforms somehow. Perhaps a compile-time error. I've tried to implement complex support for s390[x] in libffi to get a feeling how it works. I could write a patch that adds FFI_TYPE_COMPLEX (with value 15) that takes one base type as an argument, and provide implementations for s390[x]. That leaves the question how to handle targets that have not implemented the new type. * Compile time error * Runtime assertion if FFI_TYPE_COMPLEX is used * Runtime error if FFI_TYPE_COMPLEX is used I've no real preference here as this choice it won't affect s390[x], but I could implement error handling for all targets. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany