On Tue, Sep 21, 2021 at 4:30 PM Joseph Myers <jos...@codesourcery.com> wrote:
> On Tue, 21 Sep 2021, Jakub Jelinek via Gcc-patches wrote: > > > On Tue, Sep 21, 2021 at 02:15:59PM +0100, Roger Sayle wrote: > > > Can you double check? Integer division by zero is undefined, but > isn't floating point > > > division by zero defined by the appropriate IEEE standards? > > > > https://eel.is/c++draft/expr.mul#4 doesn't make the division by zero > > behavior conditional on integral types. > > C has similar wording. > > The position for C is that Annex F semantics take precedence over all the > ways in which floating-point arithmetic has undefined behavior in the main > body of the standard. So floating-point overflow and division by zero are > fully defined in the presence of Annex F support, while out-of-range > conversions from floating point to integer types produce an unspecified > value (not necessarily the same unspecified value for different executions > of the conversion in the abstract machine - as discussed in bug 93806, GCC > can get that wrong and act as if a single execution of such a conversion > in the abstract machine produces more than one result). > > In C, as specified in Annex F, initializers for floating-point objects > with static or thread storage duration are evaluated with exceptions > discarded and the default rounding mode in effect; 7.0 / 0.0 is a fully > valid initializer for such an object to initialize it to positive > infinity. As I understand it, the question for this thread is whether C++ > constexpr should have a similar rule to C static initializers (which ought > to apply to 1.0 / 3.0, raising inexact, just as much as to 7.0 / 0.0). > The C rules seem to be 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. I think following the same rules for C++ would be appropriate in a diagnosing context: warn and continue. In a template argument deduction (SFINAE) context, where errors become silent substitution failures, it's probably better to treat them as non-constant. Jason
