[Cfp-interest 2174] AI to reword footnote about transformations

[Jim Thomas]

[Cfp-interest 2173 was accidentally sent before it was quite finished. Trying again ...

Action item:
>     Jim: Reword the footnote for CFP2153 and show it to CFP before submitting it to WG14.
> 


Please review this rewording and send me comments ASAP:

399) Implementations might have non-required features that invalidate these and other transformations that remove arithmetic operators. Examples include strict support for signaling NaNs (an optional feature) and alternate exception handling (not included in this specification).

- Jim Thomas

> On Sep 28, 2021, at 2:40 PM, Jim Thomas <jaswthomas at sbcglobal.net <mailto:jaswthomas at sbcglobal.net>> wrote:
> 
> After offline discussion with Fred, I'd like to suggest the following rewording of the  footnote:
> 
> 399) Strict support for signaling NaNs (an optional feature) and alternate exception handling (not included in this specification) would invalidate these and other transformations that remove arithmetic operators.
> 
> - Jim Thomas
> 
> 
>> On Sep 26, 2021, at 2:17 PM, Jim Thomas <jaswthomas at sbcglobal.net <mailto:jaswthomas at sbcglobal.net>> wrote:
>> 
>> The relevant text noted in [Cfp-interest 2106] is:
>> 
>>> F.9.2 "Expression transformations":
>>> 
>>>  1 × x and x/1 → x     The expressions 1 × x, x/1, and x may be
>>>                        regarded as equivalent (on IEC 60559 machines,
>>>                        among others).399)
>>> 
>>>  399) Strict support for signaling NaNs — not required by this
>>>  specification — would invalidate these and other transformations
>>>  that remove arithmetic operators.
>>> 
>> 
>> 
>> F.8 #2 says “… The specification in this annex assumes IEC 60559 default exception handling ….” Given that, I think the statement is correct.
>> 
>> Since we do mention alternate exception handling in other contexts, we might consider expanding the footnote:
>> 
>> 399) Strict support for signaling NaNs and alternate exception handling — neither required by this specification — would invalidate these and other transformations that remove arithmetic operators.
>> 
>> - Jim Thomas
>> 
>>> On Sep 23, 2021, at 6:35 AM, Vincent Lefevre <vincent at vinc17.net <mailto:vincent at vinc17.net>> wrote:
>>> 
>>> On 2021-09-12 18:39:08 -0700, Jim Thomas wrote:
>>>> C Annex F requires default exception handling and doesn’t provide a
>>>> way to change to alternate exception handling. In this context the
>>>> statement is correct.
>>> 
>>> The C standard does not provide a way to change to alternate
>>> exception handling, but it allows an implementation to do so.
>>> This is the problem here.
>>> 
>>> There are notes in the standard about that, e.g. 220 in C17 "[...]
>>> enabled traps for floating-point exceptions [...]" and 222 "IEC 60559
>>> systems have a default non-stop mode, and typically at least one other
>>> mode for trap handling or aborting".
>>> 
>>> There's also F.8 "Floating-point environment", which says "It includes
>>> also IEC 60559 dynamic rounding precision and trap enablement modes,
>>> if the implementation supports them."
>>> 
>>> F.8.3 makes this clear:
>>> 
>>>  At program startup the floating-point environment is initialized as
>>>  prescribed by IEC 60559:
>>> [...]
>>>  - Trapping or stopping (if supported) is disabled on all
>>>    floating-point exceptions.
>>> 
>>> If the intent were to disallow trapping, the standard would not say
>>> "At program startup", but for the whole program execution.
>>> 
>>> -- 
>>> Vincent Lefèvre <vincent at vinc17.net <mailto:vincent at vinc17.net>> - Web: <https://www.vinc17.net/ <https://www.vinc17.net/>>
>>> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/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 <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 <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/20210930/d102d321/attachment-0001.htm>