From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53192 invoked by alias); 2 May 2016 21:47:40 -0000 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 Received: (qmail 53177 invoked by uid 89); 2 May 2016 21:47:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*Ad:D*eu, King, H*Ad:U*tkoenig, 978 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 02 May 2016 21:47:38 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axLgb-0000gg-9l for gcc-patches@gcc.gnu.org; Mon, 02 May 2016 17:47:34 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:33914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axLgb-0000YA-3o for gcc-patches@gcc.gnu.org; Mon, 02 May 2016 17:47:25 -0400 Received: from localhost by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 2 May 2016 15:46:50 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 2 May 2016 15:46:47 -0600 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: meissner@ibm-tiger.the-meissners.org X-IBM-RcptTo: fxcoudert@gcc.gnu.org;gcc-patches@gcc.gnu.org;janus@gcc.gnu.org;jb@gcc.gnu.org;jvdelisle@gcc.gnu.org;pault@gcc.gnu.org;tkoenig@gcc.gnu.org Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 81FDD3E40048; Mon, 2 May 2016 15:46:46 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u42LkkoP38142004; Mon, 2 May 2016 14:46:46 -0700 Received: from d03av01.boulder.ibm.com (localhost [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u42LkkQA020227; Mon, 2 May 2016 15:46:46 -0600 Received: from ibm-tiger.the-meissners.org (dhcp-9-32-77-111.usma.ibm.com [9.32.77.111]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u42LkjRQ020219; Mon, 2 May 2016 15:46:46 -0600 Received: by ibm-tiger.the-meissners.org (Postfix, from userid 500) id 1569645EAA; Mon, 2 May 2016 17:46:44 -0400 (EDT) Date: Mon, 02 May 2016 21:47:00 -0000 From: Michael Meissner To: FX Cc: Michael Meissner , Bernd Schmidt , Janne Blomqvist , Tobias Burnus , "FranC'ois-Xavier Coudert" , Jerry DeLisle , Erik Edelmann , Daniel Franke , Thomas KC6nig , Daniel Kraft , Toon Moene , Mikael Morin , tobias.schlueter@physik.uni-muenchen.de, Paul Thomas , Janus Weil , Segher Boessenkool , gcc-patches@gcc.gnu.org, David Edelsohn , Bill Schmidt Subject: Re: [PATCH #3], Fix _Complex when there are multiple FP types the same size Message-ID: <20160502214642.GA24307@ibm-tiger.the-meissners.org> Mail-Followup-To: Michael Meissner , FX , Bernd Schmidt , Janne Blomqvist , Tobias Burnus , FranC'ois-Xavier Coudert , Jerry DeLisle , Erik Edelmann , Daniel Franke , Thomas KC6nig , Daniel Kraft , Toon Moene , Mikael Morin , tobias.schlueter@physik.uni-muenchen.de, Paul Thomas , Janus Weil , Segher Boessenkool , gcc-patches@gcc.gnu.org, David Edelsohn , Bill Schmidt References: <20160428210613.GA29745@ibm-tiger.the-meissners.org> <20160428221006.GC6575@gate.crashing.org> <20160428234057.GA20519@ibm-tiger.the-meissners.org> <20160429205127.GA19596@ibm-tiger.the-meissners.org> <20160430160045.GA15163@gate.crashing.org> <572731F3.2060104@redhat.com> <20160502211024.GA17046@ibm-tiger.the-meissners.org> <84EB8F4B-103C-4534-904E-A2A7CA067A7F@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <84EB8F4B-103C-4534-904E-A2A7CA067A7F@gmail.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16050221-0005-0000-0000-00002E4E4A83 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 32.97.110.150 X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00140.txt.bz2 On Mon, May 02, 2016 at 11:24:25PM +0200, FX wrote: > Hi Michael, > > Thanks for letting us know. > > Right now, the Fortran front-end uses the following real modes: > - those corresponding to {float,double,long_double}_type_node > - TFmode (if libquadmath support is enabled) > and then uses the corresponding complex modes. > > So, I guess the question in your case is: in each compiler settings, is there a TFmode? If so, that would not play nice: the front-end current does not handle several real modes with equal precision. There is a TFmode. Right now, the default for TFmode is IBM extended double, and __float128 is a keyword added to C/C++ to get the IEEE 128-bit floating point type. At the moment, libquadmath is not enabled (complex support is one of the issues, and having all of the built-ins registers, etc. is another), but I'm hoping in the GCC 7 time frame to get it supported. There is an option to switch the default from IBM extended double to IEEE 128-bit, but we need to enhance the libraries before we can let users use it. Ideally by the time GCC 7 is released, users will be able to use IEEE 128-bit floating point as their default long double format. Our motivation is that the upcoming power9 hardware has IEEE 128-bit hardware support (and the fact that there are a lot of accuracy issues with the current IBM extended double format). So, I'm trying to do these stepps in a piecemeal fashion, rather than having one giant flag day. > In case you want to test, simple Fortran code to create a 128-bit real x and complex y is: > > real(kind=16) :: x > complex(kind=16) :: y > > I’m guessing if that emits the correct code in both settings, the rest should be fine. Yes. I suspect right now, there isn't an issue, since you are using the default type nodes. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797