<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">After offline discussion with Fred, I'd like to suggest the following rewording of the footnote:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">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.</div></div></blockquote><div class=""><div class=""><br class=""></div></div><div class=""><div class="">- Jim Thomas</div></div><div class=""><div class=""><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 26, 2021, at 2:17 PM, Jim Thomas <<a href="mailto:jaswthomas@sbcglobal.net" class="">jaswthomas@sbcglobal.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">The relevant text noted in [Cfp-interest 2106] is:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">F.9.2 "Expression transformations":<br class=""><br class=""> 1 × x and x/1 → x The expressions 1 × x, x/1, and x may be<br class=""> regarded as equivalent (on IEC 60559 machines,<br class=""> among others).399)<br class=""><br class=""> 399) Strict support for signaling NaNs — not required by this<br class=""> specification — would invalidate these and other transformations<br class=""> that remove arithmetic operators.<br class=""><br class=""></blockquote></div><div class=""><br class=""></div><div class="">F.8 #2 says “… The specification in this annex assumes IEC 60559 default exception handling ….” Given that, I think the statement is correct.</div><div class=""><br class=""></div><div class="">Since we do mention alternate exception handling in other contexts, we might consider expanding the footnote:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">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.</div></blockquote><div class=""><br class=""></div><div class="">- Jim Thomas</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 23, 2021, at 6:35 AM, Vincent Lefevre <<a href="mailto:vincent@vinc17.net" class="">vincent@vinc17.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 2021-09-12 18:39:08 -0700, Jim Thomas wrote:<br class=""><blockquote type="cite" class="">C Annex F requires default exception handling and doesn’t provide a<br class="">way to change to alternate exception handling. In this context the<br class="">statement is correct.<br class=""></blockquote><br class="">The C standard does not provide a way to change to alternate<br class="">exception handling, but it allows an implementation to do so.<br class="">This is the problem here.<br class=""><br class="">There are notes in the standard about that, e.g. 220 in C17 "[...]<br class="">enabled traps for floating-point exceptions [...]" and 222 "IEC 60559<br class="">systems have a default non-stop mode, and typically at least one other<br class="">mode for trap handling or aborting".<br class=""><br class="">There's also F.8 "Floating-point environment", which says "It includes<br class="">also IEC 60559 dynamic rounding precision and trap enablement modes,<br class="">if the implementation supports them."<br class=""><br class="">F.8.3 makes this clear:<br class=""><br class=""> At program startup the floating-point environment is initialized as<br class=""> prescribed by IEC 60559:<br class="">[...]<br class=""> - Trapping or stopping (if supported) is disabled on all<br class=""> floating-point exceptions.<br class=""><br class="">If the intent were to disallow trapping, the standard would not say<br class="">"At program startup", but for the whole program execution.<br class=""><br class="">-- <br class="">Vincent Lefèvre <<a href="mailto:vincent@vinc17.net" class="">vincent@vinc17.net</a>> - Web: <<a href="https://www.vinc17.net/" class="">https://www.vinc17.net/</a>><br class="">100% accessible validated (X)HTML - Blog: <<a href="https://www.vinc17.net/blog/" class="">https://www.vinc17.net/blog/</a>><br class="">Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)<br class="">_______________________________________________<br class="">Cfp-interest mailing list<br class=""><a href="mailto:Cfp-interest@oakapple.net" class="">Cfp-interest@oakapple.net</a><br class=""><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest" class="">http://mailman.oakapple.net/mailman/listinfo/cfp-interest</a><br class=""></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">Cfp-interest mailing list<br class=""><a href="mailto:Cfp-interest@oakapple.net" class="">Cfp-interest@oakapple.net</a><br class="">http://mailman.oakapple.net/mailman/listinfo/cfp-interest<br class=""></div></blockquote></div><br class=""></div></body></html>