On 28/09/2021 22.33, Gabriel Dos Reis via Core wrote:
> I suspect it is mostly because nobody has done the work.
Yes, and implementations seem to be happy to just sort-of
tacitly inherit the FP details from C.
Except, of course, if C++ features interact with the C++
specification sloppiness in unpleasant ways, as is the
case here.
However, I do notice that the latest C23 working draft says
for the division operator:
"The result of the / operator is the quotient from the division of the first operand by the second; the
result of the % operator is the remainder. In both operations, if the value of the second operand is
zero, the behavior is undefined."
Note the absence of a special provision for floating-point zero.
The words are the same, but undefined behavior in C isn't quite the same beast as in C++; the C specification is more of a partial specification that can be extended by implementers into the language that a particular implementation actually supports, so it's entirely feasible for a C implementation to say that they implement both ISO 9899 and ISO 60559, with the semantics of floating-point types defined by the latter (hardware deviations from 60559 aside...). But because C++ makes it a conformance requirement to respond in a certain way (during constant evaluation) to situations that ISO 14882 doesn't otherwise assign a meaning to, implementations can't implement both ISO 14882 and ISO 60559 fully unless we're careful to leave the right shape of hole in our standard, marking the overlapping cases not as UB but as something like implementation-defined.
However, Annex F.3 seems to override that when IEC 60559 is supported.
Jens
> @Hubert <mailto:hubert.reinterpretcast@gmail.com> – could you offer some clarity on this part?
>
>
>
> -- Gaby
>
>
>
> *From:* Core <core-bounces@lists.isocpp.org> *On Behalf Of *Richard Smith via Core
> *Sent:* Tuesday, September 28, 2021 1:07 PM
> *To:* sg12@lists.isocpp.org
> *Cc:* Richard Smith <richardsmith@googlers.com>; SG6 numerics <sci@lists.isocpp.org>; core@lists.isocpp.org
> *Subject:* Re: [isocpp-core] [SG12] constexpr and FP exceptions (was: Implementation defining undefined behavior)
>
>
>
> Yes, I think this would be an improvement, but it would also be a normative change. [expr.mul]/4 is very explicit and clear that division by zero is undefined behavior, even for floating-point types.
>
>
>
> Is there a reason we haven't re-synced our floating-point specification with C's much more explicit and nailed-down formulation, other than that no-one has done the work? (I seem to recall Hubert mentioning that the C specification may not properly describe the PPC double-double representation in some ways. It would be nice to fix that if my recollection is right.)
>
>
>
> On Tue, Sep 28, 2021 at 10:43 AM Gabriel Dos Reis via SG12 <sg12@lists.isocpp.org <mailto:sg12@lists.isocpp.org>> wrote:
>
> 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@lists.isocpp.org <mailto:core-bounces@lists.isocpp.org>> *On Behalf Of *Jason Merrill via Core
> *Sent:* Tuesday, September 28, 2021 6:38 AM
> *To:* Hubert Tong <hubert.reinterpretcast@gmail.com <mailto:hubert.reinterpretcast@gmail.com>>
> *Cc:* Jason Merrill <jason@redhat.com <mailto:jason@redhat.com>>; SG6 numerics <sci@lists.isocpp.org <mailto:sci@lists.isocpp.org>>; C++ Core Language Working Group <core@lists.isocpp.org <mailto:core@lists.isocpp.org>>; sg12@lists.isocpp.org <mailto:sg12@lists.isocpp.org>
> *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@gmail.com <mailto:hubert.reinterpretcast@gmail.com>> wrote:
>
> On Tue, Sep 21, 2021 at 11:44 AM Herring, Davis via Core <core@lists.isocpp.org <mailto:core@lists.isocpp.org>> 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%7Cc36fdb31b66348be763408d982bb98a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637684564515290002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FXLv%2FvJw75OpjW6a91BbXyuGLOlJT%2BfYAqQoK8SnztI%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%7Cc36fdb31b66348be763408d982bb98a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637684564515299997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wrvH9T%2BuwhZy9fNcCcXlRYC5hLX2Tctn5mON5AvF6bI%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
>
> _______________________________________________
> SG12 mailing list
> SG12@lists.isocpp.org <mailto:SG12@lists.isocpp.org>
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg12&data=04%7C01%7Cgdr%40microsoft.com%7Cc36fdb31b66348be763408d982bb98a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637684564515299997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=w%2F06atHBCGx5u2LfspfIdT%2BR4wpK%2BRUaDhwGAyuZh7Q%3D&reserved=0>
> Link to this post: http://lists.isocpp.org/sg12/2021/09/0973.php <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fsg12%2F2021%2F09%2F0973.php&data=04%7C01%7Cgdr%40microsoft.com%7Cc36fdb31b66348be763408d982bb98a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637684564515309990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gy1vIdCw6MhUvU19dpuXZXQAimXVzKDyH3Gjqkcs%2BVY%3D&reserved=0>
>
>
> _______________________________________________
> Core mailing list
> Core@lists.isocpp.org
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2021/09/11578.php
>