On Tue, Sep 21, 2021 at 11:48 AM Hubert Tong <
hubert.reinterpretcast_at_[hidden]> wrote:

> On Tue, Sep 21, 2021 at 11:44 AM Herring, Davis via Core <
> core_at_[hidden]> wrote:
>
>> > I'm thinking specifically about floating point division by zero, which
>> > sometimes hits a hardware exception and sometimes produces
>> > floating-point infinity (when is_iec559 is true).
>> >
>> > As with other cases of undefined behavior, this is made testable by
>> > constexpr. Can an implementation say that a construct that is
>> > undefined in the C++ standard is defined in that implementation, and
>> > therefore accept it in constexpr?
>>
>> For this case in particular, SG6 (or at least Lawrence) has in the past
>> recommended against supporting it <
>> https://wiki.edg.com/bin/view/Wg21issaquah2016/CoreWorkingGroup#Core_issue_2168_Narrowing_conver>
>> <https://lists.isocpp.org/sci/2016/03/0000.php>.
>>
>
It looks to me like those links are talking about narrowing, not division
by zero. And narrowing isn't undefined, it's ill-formed.

For division by zero specifically, why doesn't the definition in IEC559
count as defined behavior, when we advertise that a type conforms to that
standard? In C's Annex F, it seems to:

F.8.2 Translation
During translation the IEC 60559 default modes are in effect:
 — The rounding direction mode is rounding to nearest.
 — The rounding precision mode (if supported) is set so that results are
not shortened.
 — Trapping or stopping (if supported) is disabled on all floating-point
exceptions.
Recommended practice:
The implementation should produce a diagnostic message for each
translation-time floating-point exception, other than “inexact”; the
implementation should then proceed with the translation of the program.

Jason