From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 992B23857C4C for ; Mon, 23 Nov 2020 20:14:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 992B23857C4C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 0ANKDxhZ020149; Mon, 23 Nov 2020 14:13:59 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 0ANKDwcg020146; Mon, 23 Nov 2020 14:13:58 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 23 Nov 2020 14:13:58 -0600 From: Segher Boessenkool To: Jakub Jelinek Cc: Michael Meissner , gcc-patches@gcc.gnu.org, David Edelsohn , Bill Schmidt , Peter Bergner Subject: Re: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test. Message-ID: <20201123201358.GK2672@gate.crashing.org> References: <20201115171747.GA10343@ibm-toto.the-meissners.org> <20201118214320.GQ2672@gate.crashing.org> <20201118215349.GT3788@tucnak> <20201118222909.GR2672@gate.crashing.org> <20201119080805.GA27187@ibm-toto.the-meissners.org> <20201119140302.GS2672@gate.crashing.org> <20201121052730.GA17995@ibm-toto.the-meissners.org> <20201123185929.GH2672@gate.crashing.org> <20201123191049.GG3788@tucnak> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201123191049.GG3788@tucnak> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 20:15:00 -0000 On Mon, Nov 23, 2020 at 08:10:49PM +0100, Jakub Jelinek wrote: > On Mon, Nov 23, 2020 at 12:59:29PM -0600, Segher Boessenkool wrote: > > On Sat, Nov 21, 2020 at 12:27:30AM -0500, Michael Meissner wrote: > > > On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote: > > > > Sure -- I am suggesting to always define __IBM128_MAX__ and the like, > > > > which then can be used to define LDBL_MAX, but also can be used > > > > directly. > > > > > > I have posted patches for this as a new set of patches. Rather than trying to > > > create IBM 128-bit long double min/max/etc. defines, I just marked the test as > > > needing IBM 128-bit long double. > > > > > > I did look into providing defines for these. Unfortunately the function that > > > creates these (builtin_define_float_constants) is static. And the caller of > > > that function (c_cpp_builtins) does not have a target hook or other method to > > > provide for these defines for MD specific floating point types. > > > > So create the defines from somewhere in the backend, instead? This > > isn't rocket science. > > > > You can even leave the existing LDBL defines alone if you just override > > them later. > > The current defines are quite complex code, because defining them is very > expensive and we don't want to pay that price at every compilation start > when most of the compilations never use those macros. > So they are magic deferred macros. Ah, so defining later will not work, or it will be quite fragile at least. So that won't fly :-/ We can provide IBM128 etc. macros for this just fine of course, but using that for the LDBL is hard then, so perhaps we should not do that second step, certainly not in stage > 1. Thanks, Segher