[Cfp-interest 2677] Re: floating constants issue

[Jim Thomas]

> On Jan 31, 2023, at 8:14 AM, Hans Boehm <boehm at acm.org> wrote:
> 
> I think this means that the same integer constant expression can now evaluate to different integers depending on the rounding mode.

Yes, I think that’s right.

> Thus
> 
> int a[1 + (int)0.99999999999999999999999999999999999)]; may not be type compatible with itself, if it occurs in different rounding mode contexts.

> 
> I'm not enough of a language lawyer and C compiler expert to determine whether this can be made to work. But I suspect the reason for the original rule was that somebody thought it couldn't.

I’d guess the original rule was to disallow the translator from giving different results because of internal reasons unrelated to the semantics of the source code.

- Jim Thomas

> 
> Hans
> 
> On Tue, Jan 31, 2023 at 7:40 AM Jim Thomas <jaswthomas at sbcglobal.net <mailto:jaswthomas at sbcglobal.net>> wrote:
>> 
>> 
>>> On Jan 30, 2023, at 5:51 PM, Vincent Lefevre <vincent at vinc17.net <mailto:vincent at vinc17.net>> wrote:
>>> 
>>> On 2023-01-30 15:19:52 -0800, Jim Thomas wrote:
>>>> 6.4.4.2 #8 says:
>>>> 
>>>> All floating constants of the same source form 83) shall convert to the same internal format with the same value.
>>>> 
>>>> With the FENV_ROUND and FENV_DEC_ROUND pragmas this is no longer true. For example, 7.6.2 #4 for FENV_ROUND says "Floating constants (6.4.4.2) of a standard floating type that occur in the scope of a constant rounding mode shall be interpreted according to that mode."
>>>> 
>>>> This was pointed out in a recent email which I was unable to find. Thanks to the sender.
>>> 
>>> I posted the remark about 6.4.4.2 #8 in Cfp-interest 2634:
>>>  http://mailman.oakapple.net/pipermail/cfp-interest/2023-January/002648.html
>>> 
>>> But I hadn't noticed the issue with FENV_ROUND.
>>> 
>>>> A fix would be to replace the sentence with something like:
>>>> 
>>>> All floating constants of the same source form shall convert to the same internal format. All floating constants of the same source form that are subject to the same translation-time rounding direction (either the default or a rounding direction set by an FENV_ROUND or FENV_DEC_ROUND pragma) shall convert to the same internal format with the same value.
>>>> 
>>>> or
>>>> 
>>>> All floating constants of the same source form shall convert to the same internal format and, provided they are subject to the same translation-time rounding direction (either the default or a rounding direction set by an FENV_ROUND or FENV_DEC_ROUND pragma), to the same value.
>>> 
>>> Both are unclear. What if it is set to FE_DYNAMIC?
>> 
>> Maybe
>> 
>> All floating constants of the same source form shall convert to the same internal format and, provided they are subject to the same translation-time rounding direction (either the default or a constant rounding mode other that FE_DYNAMIC set by an FENV_ROUND or FENV_DEC_ROUND pragma), to the same value.
>> 
>> But that would suggest that same-form floating constants could have different values under FE_DYNAMIC. Setting to FE_DYNAMIC should not affect the translation time conversion of floating constants in that they would still get default translation-time rounding.
>> 
>>> 
>>> BTW, is there a way to restore the static rounding mode when
>>> outside external declarations? This would be important if one
>>> wants to use this pragma in a header file.
>> 
>> It can be “restored" to FE_DYNAMIC which serves as a “default”.
>> 
>> - Jim Thomas
>>> 
>>> -- 
>>> Vincent Lefèvre <vincent at vinc17.net <mailto:vincent at vinc17.net>> - Web: <https://www.vinc17.net/>
>>> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
>>> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>>> _______________________________________________
>>> Cfp-interest mailing list
>>> Cfp-interest at oakapple.net <mailto:Cfp-interest at oakapple.net>
>>> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>> 
>> 
>> _______________________________________________
>> Cfp-interest mailing list
>> Cfp-interest at oakapple.net <mailto:Cfp-interest at oakapple.net>
>> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230201/3b7c498d/attachment.htm>