I suspect it is mostly because nobody has done the work.

@Hubert – 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> 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> On Behalf Of Jason Merrill via Core
Sent: Tuesday, September 28, 2021 6:38 AM
To: Hubert Tong <hubert.reinterpretcast@gmail.com>
Cc: Jason Merrill <jason@redhat.com>; SG6 numerics <sci@lists.isocpp.org>; C++ Core Language Working Group <core@lists.isocpp.org>; 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> wrote:

On Tue, Sep 21, 2021 at 11:44 AM Herring, Davis via Core <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://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

_______________________________________________
SG12 mailing list
SG12@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
Link to this post: http://lists.isocpp.org/sg12/2021/09/0973.php