From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118444 invoked by alias); 21 Jun 2016 15:43:23 -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 118410 invoked by uid 89); 21 Jun 2016 15:43:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=TFmode, *f128, float128_ieee_p, FLOAT128_IEEE_P X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 21 Jun 2016 15:43:12 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-03.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1bFNpW-0003jP-3p from joseph_myers@mentor.com ; Tue, 21 Jun 2016 08:43:10 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-03.mgc.mentorg.com (137.202.0.108) with Microsoft SMTP Server id 14.3.224.2; Tue, 21 Jun 2016 16:43:08 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1bFNpT-0000Hi-BK; Tue, 21 Jun 2016 15:43:07 +0000 Date: Tue, 21 Jun 2016 15:43:00 -0000 From: Joseph Myers To: Bill Schmidt CC: GCC Patches , , , , , , , , , , , Subject: Re: Implement C _FloatN, _FloatNx types In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-06/txt/msg01508.txt.bz2 On Tue, 21 Jun 2016, Bill Schmidt wrote: > I haven't read through the patch in detail yet, but thank you for the > very thorough description! For PowerPC, we currently have a lot > invested in having __float128 correspond to KFmode for the time being, > during the transition while supporting both IEEE-128 and IBM long > double. (I was not aware of the problem with q-suffix constants being > treated as TFmode, which will need to be fixed.) I'm currently in > process of developing the minimal set of *f128 built-ins required for > glibc, using __float128 and KFmode. > > Can we please keep this correspondence for now? Do you foresee any > further concerns with staying on that path until we can fully throw the > switch to move away from IBM long double? The question is what mode is used for _Float128 (and thus for __float128, which is now a typedef for _Float128) in the FLOAT128_IEEE_P (TFmode) case (that is, when TARGET_IEEEQUAD is true). I see no problems with that mode being KFmode instead of TFmode if that's what's preferred; I'll make that change in the next revision of my patch. Of course, you should make *q constants match, so that they are consistent with *f128 constants. -- Joseph S. Myers joseph@codesourcery.com