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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 25E81385783E for ; Sat, 8 Jan 2022 11:11:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 25E81385783E Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-210-XsxE8gwpOby9LYcfaU5xhQ-1; Sat, 08 Jan 2022 06:11:02 -0500 X-MC-Unique: XsxE8gwpOby9LYcfaU5xhQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 21E801083F60; Sat, 8 Jan 2022 11:11:01 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.2.16.169]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A060F7E11F; Sat, 8 Jan 2022 11:11:00 +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 208BAvYC1075438 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 8 Jan 2022 12:10:57 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 208BAu8C1075437; Sat, 8 Jan 2022 12:10:56 +0100 Date: Sat, 8 Jan 2022 12:10:56 +0100 From: Jakub Jelinek To: Thomas Koenig , Michael Meissner , Segher Boessenkool , "fortran@gcc.gnu.org" , Peter Bergner , Bill Schmidt , gcc-patches@gcc.gnu.org, David Edelsohn Subject: Re: [power-ieee128] OPEN CONV Message-ID: <20220108111056.GT2646553@tucnak> Reply-To: Jakub Jelinek References: <20220104110749.GC2646553@tucnak> <20220107092202.GE2646553@tucnak> <28f0a876-7281-936d-f727-cb7067c052f9@netcologne.de> <20220107195220.GP2646553@tucnak> <332da363-1c64-e1bf-a05a-d412c600f580@netcologne.de> <20220107214813.GR2646553@tucnak> <124cfb8a-e3d0-207c-8dcb-bdfab29372cb@netcologne.de> <20220108110038.GS2646553@tucnak> MIME-Version: 1.0 In-Reply-To: <20220108110038.GS2646553@tucnak> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 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=-3.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_MANYTO, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2022 11:11:07 -0000 On Sat, Jan 08, 2022 at 12:00:38PM +0100, Jakub Jelinek via Gcc-patches wrote: > And IMHO the default like for byte-swapping should be the native > format, i.e. the one the program actually used. One reason for that is that neither conversion is lossless, neither format is a subset or superset of the other. Yes, IEEE quad has both much bigger exponent range (-16382..16383 vs. -1022..1023) and slightly bigger fixed precision (113 vs. 106 bits). But IBM extended has that weirdo numerically awful flexible precision where certain numbers can have much bigger precision than those 106 bits, up to 2048+52 or so. So there is rounding in both directions. So, after distros switch to -mabi=ieeelongdouble by default or when people use -mabi=ieeelongdouble on their programs, they'd better store that format into data files by default, without the need of some magic CONVERT= options, env vars or command line options. Only in the case where they need to interact with -mabi=ibmlongdouble environments, they need to take some action. Jakub