[Cfp-interest 2669] Re: floating constants issue

[Hans Boehm]

I think this means that the same integer constant expression can now
evaluate to different integers depending on the rounding mode. 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.

Hans

On Tue, Jan 31, 2023 at 7:40 AM Jim Thomas <jaswthomas at sbcglobal.net> wrote:

>
>
> On Jan 30, 2023, at 5:51 PM, Vincent Lefevre <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> - 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
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>
>
>
> _______________________________________________
> Cfp-interest mailing list
> 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/20230131/67f460df/attachment-0001.htm>