<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=""><div class=""><span style="font-size: 10pt; font-family: Arial, sans-serif;" class="">Action item:</span></div><div class=""><blockquote type="cite" class=""><span style="font-family: Arial, sans-serif; font-size: 13.333333015441895px;" class="">Jim: Look at what is said in exception handling and make sure remainder underflow is addressed as per Jim's/Fred/David's email regarding 18661-1 and 754 (2018/04/09). &nbsp; &nbsp;</span><br style="font-family: Arial, sans-serif; font-size: 13.333333015441895px;" class=""></blockquote><!--EndFragment--></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">F.10 (with or without 18661-1) says:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">7 The ‘‘underflow’’ floating-point exception is raised whenever a result is tiny (essentially&nbsp;subnormal or zero) and suffers loss of accuracy.371)&nbsp;</div><div class=""><br class=""></div><div class="">371) IEC 60559 allows different definitions of underflow. They all result in the same&nbsp;values, but differ on&nbsp;when the floating-point exception is raised.</div></blockquote><div class=""><br class=""></div><div class="">and the remainder spec in annex F with 18661-1 does not mention underflow. This slips over the subtle definition of 754 underflow, but I think it's is ok because exact underflow is not user-detectable in C11 with 18661-1.</div><div class=""><br class=""></div><div class="">With 18661-5 exact underflow (including remainder underflow) might be detectable. The spec there is careful to reflect the subtlety. The alternate exception handling spec says:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">[2] For the “underflow”&nbsp;exception, the chosen exception handling occurs if the exception is raised,&nbsp;whether the default&nbsp;result would be exact or inexact, unless stated otherwise.</div></blockquote><div class=""><br class=""></div><div class="">The abrupt underflow spec says:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">—&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;abrupt&nbsp;underflow. If an “underflow” floating-point exception occurs (see IEC&nbsp;60559), the operation delivers a result with&nbsp;magnitude zero or the minimum&nbsp;normal magnitude (for the result format) and with the same sign as the default&nbsp;result, sets the&nbsp;“underflow” floating-point exception flag, and raises the “inexact”&nbsp;floating-point exception. …</div></blockquote><div class=""><br class=""></div><div class="">The try-catch spec says:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">[14]&nbsp;In most cases, the&nbsp;try&nbsp;and&nbsp;catch&nbsp;actions can be implemented like&nbsp;delayed-try&nbsp;and&nbsp;delayed-catch&nbsp;actions, though not for the&nbsp;“underflow” exception&nbsp;(which occurs without causing the “underflow” flag to be set, in cases of exact&nbsp;subnormal results). Such an&nbsp;implementation would not always handle the first&nbsp;occurring designated exception, as recommended.</div><div class=""><br class=""></div></blockquote>I don’t see any needed to change 18661-1 or 18661-5.<div class=""><br class=""></div><div class=""><br class=""></div><div class="">- Jim Thomas</div></body></html>