[Cfp-interest 2158] Re: defect in ISO C about underflow with exact subnormal

[Jim Thomas]

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> 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
> 
> _______________________________________________
> 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/20210928/7920678d/attachment.htm>