From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 9EC383833005 for ; Wed, 18 Nov 2020 21:54:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9EC383833005 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-11-oQ9_EjzBPJSYCWufNWOvrQ-1; Wed, 18 Nov 2020 16:54:01 -0500 X-MC-Unique: oQ9_EjzBPJSYCWufNWOvrQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2C3E38144E0; Wed, 18 Nov 2020 21:54:00 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-127.ams2.redhat.com [10.36.113.127]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B348E60636; Wed, 18 Nov 2020 21:53:59 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 0AILrupu1013142 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 22:53:57 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 0AILrn541013141; Wed, 18 Nov 2020 22:53:49 +0100 Date: Wed, 18 Nov 2020 22:53:49 +0100 From: Jakub Jelinek To: Segher Boessenkool 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: <20201118215349.GT3788@tucnak> Reply-To: Jakub Jelinek References: <20201115171747.GA10343@ibm-toto.the-meissners.org> <20201118214320.GQ2672@gate.crashing.org> MIME-Version: 1.0 In-Reply-To: <20201118214320.GQ2672@gate.crashing.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Wed, 18 Nov 2020 21:54:07 -0000 On Wed, Nov 18, 2020 at 03:43:20PM -0600, Segher Boessenkool wrote: > Hi! > > On Sun, Nov 15, 2020 at 12:17:47PM -0500, Michael Meissner wrote: > > --- a/gcc/testsuite/gcc.target/powerpc/pr70117.c > > +++ b/gcc/testsuite/gcc.target/powerpc/pr70117.c > > @@ -9,9 +9,11 @@ > > 128-bit floating point, because the type is not enabled on those > > systems. */ > > #define LDOUBLE __ibm128 > > +#define IBM128_MAX ((__ibm128) 1.79769313486231580793728971405301199e+308L) > > This is the IEEE QP float number 43fefffffffffffff7ffffffffffff80 which > I very much doubt is the maximum finite double-double? See the 0 in the Numbers without the 0 in the middle-end aren't valid, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95450#c6 for more details. Without the 0 in the middle the double double number rounded to double would require increasing the higher double, and as it is the largest representable finite number, that is not possible. Jakub