I think you're right, the compiler can follow IEEE-754 rules in general, but as written it couldn't do so for constant expressions.

I find that rule to be really weird in general. Does that mean that, for example, if you try to use "1 << 32" in a constant expression, then whether it's actually a constant expression will depend on the target architecture? I wonder what the rationale is there.

I find that rule to be really weird in general. Does that mean that, for example, if you try to use "1 << 32" in a constant expression, then whether it's actually a constant expression will depend on the target architecture? I wonder what the rationale is there.

Yes, that's right. The rationale is that it's not particularly different from the way constant expressions in C have always worked: The compiler knows full well whether

    static const int x = 99999999999;

or

    static const int x = 1 << 32;

represents a valid assignment within the range of int on the target platform, and responds accordingly. constexpr just generalizes that behavior to more of the expression machinery.

Right, but those examples still compile, they just invoke UB. Normally you want to avoid that, but sometimes you actually do want to, and the fact that the result is UB gives the compiler the freedom to support additional semantics.

For something closer to the original topic, consider:

    static const double x = 1.0/0.0;

That's UB, but the compiler is free to declare that it follows IEEE-754 and fully support this. The equivalent with constexpr doesn't allow that same freedom, and the compiler must consider 1.0/0.0 to not be a constexpr.

Ah, I see what you mean. A few years of warnings-as-errors mode made me forget that the most bizarre constant expressions (not constexprs) will compile even if their results or what you do with them are complete nonsense.

I'd argue that the constexpr behavior is an improvement, in that it enables errors for large swaths of obviously buggy expressions without breaking backward compatibility. If the committee wants to remove float-division-by-0 from the set of UB expressions, they should do that independently of the rules for constexprs/constant expressions (as some Googling gives me the impression the C standard did with Annex F).

Generally, I think compiler vendors should not be distinguishing themselves by "reliably" implementing some "defined" behavior for what the standard declares to be UB[1]. At that point you're effectively implementing a proprietary language extension. "Implementation-defined" parts of the standard—and tooling/libraries, of course—are where vendors should be differentiating.

[1] I had a very traumatic experience with HP-UX and its configurable null-pointer-dereference semantics that may be biasing me here.