From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout3.netcologne.de (cc-smtpout3.netcologne.de [89.1.8.213]) by sourceware.org (Postfix) with ESMTPS id 32C463857C7B; Fri, 7 Jan 2022 10:26:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 32C463857C7B Received: from cc-smtpin2.netcologne.de (cc-smtpin2.netcologne.de [89.1.8.202]) by cc-smtpout3.netcologne.de (Postfix) with ESMTP id 7913A1258C; Fri, 7 Jan 2022 11:26:24 +0100 (CET) Received: from [IPv6:2001:4dd7:7488:0:7285:c2ff:fe6c:992d] (2001-4dd7-7488-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd7:7488:0:7285:c2ff:fe6c:992d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin2.netcologne.de (Postfix) with ESMTPSA id 7460412051; Fri, 7 Jan 2022 11:26:16 +0100 (CET) Subject: Re: [power-ieee128] OPEN CONV To: Jakub Jelinek Cc: Michael Meissner , Segher Boessenkool , "fortran@gcc.gnu.org" , Peter Bergner , gcc-patches@gcc.gnu.org, Bill Schmidt , David Edelsohn References: <20220103153621.GL2664@tucnak> <20220103162650.GV2646553@tucnak> <20220103200026.GW2646553@tucnak> <1bd479f6-2ea6-a19d-b8e5-69d3cac7ca98@netcologne.de> <20220104110749.GC2646553@tucnak> <20220107092202.GE2646553@tucnak> From: Thomas Koenig Message-ID: <28f0a876-7281-936d-f727-cb7067c052f9@netcologne.de> Date: Fri, 7 Jan 2022 11:26:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20220107092202.GE2646553@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-NetCologne-Spam: L X-Rspamd-Queue-Id: 7460412051 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Fri, 07 Jan 2022 10:26:28 -0000 On 07.01.22 10:22, Jakub Jelinek wrote: > On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote: >> >> On 06.01.22 06:00, Michael Meissner via Fortran wrote: >> What is still missing is the conversion for unformatted I/O, both >> ways. I'll start doing some stuff on it. Just one question: >> What are functions that I can use to convert from IBM long double >> to IEEE and long double and vice versa? It was in an e-mail somewhere, >> but I cannot find it at the moment. > > So, what's the plan for that? > Can't find CONVERT= in Fortran 2018, so I assume it is a non-standard > extension, Correct. > https://www.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/file-operation-i-o-statements/open-statement-specifiers/open-convert-specifier.html#open-convert-specifier > documents the Intel one We followed Intel on that one. NAG also has it (although the details differ). > and we accept > CONVERT='native' > CONVERT='swap' > CONVERT='big_endian' > CONVERT='little_endian' > Now, I suppose for powerpc64le we want to add > some more, but the question is how they play together > with the byteswapping and how to name them, so that > it is clear they talk about REAL/COMPLEX KIND=16 format > and nothing else. Can we (or do we) want to allow > multiple comma separated strings from the orthogonal > choices, like > CONVERT='big_endian,ibm_extended' > CONVERT='swap,ieee_extended' > or add ibm_extended, ieee_extended and strings that > combine those with swap, big_endian and little_endian > ibm_extended_swap, ieee_extended_little etc.? In https://gcc.gnu.org/pipermail/fortran/2021-October/056895.html I made a suggestion how how the format could look like. I used a plus sign instead of a comma because I thought the environment variable should follow the same syntax as the CONVERT specifier, and I did not want to think about having commas in there :-) Thinking about this again after some time, I think the syntax of the environment variable would be clearer if the keywords for the two conversions were separate, so somethig like big_endian;r16_ieee;r16_ibm:10-20; for the environment variable and CONVERT="big_endian,r16_ibm" would probably be better. Best regards Thomas