That would be an improvement in clarity of the current (C++) wording. Though I don't know if 'should' would have the normative effect you're seeking...

-- Gaby

From: Core <core-bounces_at_[hidden]> On Behalf Of Jason Merrill via Core
Sent: Tuesday, September 28, 2021 6:38 AM
To: Hubert Tong <hubert.reinterpretcast_at_[hidden]>
Cc: Jason Merrill <jason_at_[hidden]>; SG6 numerics <sci_at_[hidden]>; C++ Core Language Working Group <core_at_[hidden]>; sg12_at_[hidden]
Subject: [isocpp-core] constexpr and FP exceptions (was: Implementation defining undefined behavior)

On Tue, Sep 21, 2021 at 11:48 AM Hubert Tong <hubert.reinterpretcast_at_[hidden]<mailto:hubert.reinterpretcast_at_[hidden]>> wrote:
On Tue, Sep 21, 2021 at 11:44 AM Herring, Davis via Core <core_at_[hidden]<mailto: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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.edg.com%2Fbin%2Fview%2FWg21issaquah2016%2FCoreWorkingGroup%23Core_issue_2168_Narrowing_conver&data=04%7C01%7Cgdr%40microsoft.com%7Cb9cde696a68a43f4c08e08d982853f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637684331085190522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kH0jh4F4rIkPc%2F8nIWbzP7WyWXIgTmRoms3BpmndaT8%3D&reserved=0>> <https://lists.isocpp.org/sci/2016/03/0000.php<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fsci%2F2016%2F03%2F0000.php&data=04%7C01%7Cgdr%40microsoft.com%7Cb9cde696a68a43f4c08e08d982853f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637684331085200516%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bbREgnSY4AXbntZGfewg9HG1%2FpZYNzggVywr%2FHU7zwY%3D&reserved=0>>.

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