Date: Wed, 29 Sep 2021 09:05:39 +0200
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.
However, Annex F.3 seems to override that when IEC 60559 is supported.
Jens
> @Hubert <mailto:hubert.reinterpretcast_at_[hidden]> – could you offer some clarity on this part?
>
>
>
> -- Gaby
>
>
>
> *From:* Core <core-bounces_at_[hidden]> *On Behalf Of *Richard Smith via Core
> *Sent:* Tuesday, September 28, 2021 1:07 PM
> *To:* sg12_at_[hidden]
> *Cc:* Richard Smith <richardsmith_at_[hidden]>; SG6 numerics <sci_at_[hidden]>; core_at_[hidden]
> *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_at_[hidden] <mailto:sg12_at_[hidden]>> 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_at_[hidden] <mailto: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] <mailto:hubert.reinterpretcast_at_[hidden]>>
> *Cc:* Jason Merrill <jason_at_[hidden] <mailto:jason_at_[hidden]>>; SG6 numerics <sci_at_[hidden] <mailto:sci_at_[hidden]>>; C++ Core Language Working Group <core_at_[hidden] <mailto:core_at_[hidden]>>; sg12_at_[hidden] <mailto: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%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_at_[hidden] <mailto:SG12_at_[hidden]>
> 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_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2021/09/11578.php
>
> 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.
However, Annex F.3 seems to override that when IEC 60559 is supported.
Jens
> @Hubert <mailto:hubert.reinterpretcast_at_[hidden]> – could you offer some clarity on this part?
>
>
>
> -- Gaby
>
>
>
> *From:* Core <core-bounces_at_[hidden]> *On Behalf Of *Richard Smith via Core
> *Sent:* Tuesday, September 28, 2021 1:07 PM
> *To:* sg12_at_[hidden]
> *Cc:* Richard Smith <richardsmith_at_[hidden]>; SG6 numerics <sci_at_[hidden]>; core_at_[hidden]
> *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_at_[hidden] <mailto:sg12_at_[hidden]>> 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_at_[hidden] <mailto: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] <mailto:hubert.reinterpretcast_at_[hidden]>>
> *Cc:* Jason Merrill <jason_at_[hidden] <mailto:jason_at_[hidden]>>; SG6 numerics <sci_at_[hidden] <mailto:sci_at_[hidden]>>; C++ Core Language Working Group <core_at_[hidden] <mailto:core_at_[hidden]>>; sg12_at_[hidden] <mailto: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%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_at_[hidden] <mailto:SG12_at_[hidden]>
> 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_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2021/09/11578.php
>
Received on 2021-09-29 02:05:54