Date: Wed, 29 Sep 2021 11:37:22 -0700
On Wed, Sep 29, 2021 at 12:05 AM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
> 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_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
> >
>
>
> 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_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 13:37:37