From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) by sourceware.org (Postfix) with ESMTPS id E666B3858D28 for ; Mon, 19 Sep 2022 15:35:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E666B3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.17] ([86.215.174.255]) by smtp.orange.fr with ESMTPA id aInfoyP0w94emaInfozoPW; Mon, 19 Sep 2022 17:35:13 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Mon, 19 Sep 2022 17:35:13 +0200 X-ME-IP: 86.215.174.255 Message-ID: Date: Mon, 19 Sep 2022 17:35:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 From: Mikael Morin Subject: Re: [PATCH] Fortran 2018 rounding modes changes To: FX , fortran@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, I'm coming (late) to this. Le 31/08/2022 à 20:29, FX via Fortran a écrit : > This adds new F2018 features, that are not really enabled (because their runtime support is optional). > (...) > 2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support floating-point radices other than 2. > If we accept the argument, we have to support it somehow. So for IEEE_GET_ROUNDING_MODE (*, 10), we should return IEEE_OTHER, shouldn't we? There is no problem for IEEE_SET_ROUNDING_MODE (*, 10) as there is no way this to be a valid call if radix 10 is not supported, but changing a compile time error to a runtime unexpected behavior seems like a step backwards.