From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) by sourceware.org (Postfix) with ESMTPS id 2E9A03858D32 for ; Mon, 19 Sep 2022 17:09:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2E9A03858D32 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 aKHCoz5VV94emaKHCo05cd; Mon, 19 Sep 2022 19:09:47 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Mon, 19 Sep 2022 19:09:47 +0200 X-ME-IP: 86.215.174.255 Message-ID: Date: Mon, 19 Sep 2022 19:09:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH] Fortran 2018 rounding modes changes Content-Language: en-US To: FX Cc: Fortran , gcc-patches@gcc.gnu.org References: <52A7FAB8-735E-42D8-97A6-7E4C4F108C5E@gmail.com> From: Mikael Morin In-Reply-To: <52A7FAB8-735E-42D8-97A6-7E4C4F108C5E@gmail.com> 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: Le 19/09/2022 à 18:17, FX a écrit : > Hi, > >>> 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? > > I think I disagree. We do not support any real kind with radix 10, so calling IEEE_GET_ROUNDING_MODE with RADIX=10 is invalid. Or, in another interpretation, the rounding mode is whatever-you-want-to-call it, since you cannot perform arithmetic in that radix anyway. > Hmm, not really convinced, but that's a possible interpretation, I guess. > >> 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. > > What do you mean by that? The behavior is not unexpected, the value returned by IEEE_GET_ROUNDING_MODE for RADIX=10 is irrelevant and cannot be used for anything useful. > My sentence was about IEEE_*S*ET_ROUNDING_MODE actually. My point that we previously reported an error (at compile time) to a user that would try to pass a radix 10 while we now silently do... something else that was requested (i.e. set the radix 2 rounding mode). I think it's worth at least documenting that only radix 2 is supported.