committee gonna committee. floating point has had this exact ambiguity since at least Kona 2016 and it only took one contradictory DR and three diverging compiler implementations to get a cleanup paper. progress.

lol Rust doesn’t have floating-point undefined behavior. just saying.

-ffast-math assumes no infinities, no NaNs, no signed zeros. This paper is for people who need IEEE conformance without the flag — HFT desks, numerics researchers, anyone who ships to an auditor. The rest of us just flip the flag and move on.

Eight years of writing C++ and the mental overhead of tracking which FP operations are UB vs. well-defined on which platform is genuinely exhausting. Glad this is being fixed. I still wish there was a [[strict_ieee]] attribute I could slap on a TU and stop thinking about it.

I’ve been tracking CWG2168 since the 2016 Kona meeting. What this paper doesn’t advertise loudly enough in the abstract is that it’s reversing part of the SG6 guidance from that session. The 2016 guidance said overflow to infinity should be well-defined at runtime, but infinity should not be usable as a subexpression in constant expressions — the idea being that constexpr float x = infinity() + 1; was meant to be ill-formed. This paper flips that: infinity propagation is now explicitly valid in constexpr. The justification is reasonable (all three compilers already accept it and rejecting it would break code), but it’s a policy change dressed as a clarification.

The other thing that jumps out: division by zero stays undefined. So on an IEEE 754 type, FLT_MAX * 2 is now well-defined (produces +inf), while 1.0f / 0.0f is still UB. The paper explains the reasons — signed infinity, negative zero, NaN payloads, non-IEEE types — but it means you can’t read this as “C++ finally matches IEEE 754.” Half the table is set.

In HFT we sometimes want infinity production as a sentinel — client sends a degenerate price, arithmetic propagates to inf, downstream logic catches it in a single branch instead of bounds-checking every intermediate. The “technically UB” status meant that was load-bearing on implementation-defined behavior even though every IEEE 754 compiler does the right thing. This clarification removes a sword of Damocles. Division by zero staying UB is fine; we already defensively handle denominators.

GCC 15 already implements exactly this behavior. Clang and MSVC deviate only in the constexpr overflow case — they accept FLT_MAX * 2.0f as a constant expression; this paper would reject it. This is basically standardizing existing practice. Rubber stamp.

great, constexpr floating point with NaN propagation. can’t wait for the “why is my constant evaluation 3x slower” issue reports in six months

hot take: if your safety-critical code uses floating-point at all you already have bigger problems than FP UB. fixed-point arithmetic with explicit precision tracking is the correct approach for anything where correctness actually matters.

The phrase “not mathematically defined in the domain of real number arithmetic” is new vocabulary introduced in this paper. It’s doing genuine semantic work — it’s why inf * 0 (indeterminate) fails as a constant expression while nan * 2 (propagation) passes — but it appears nowhere else in the standard and has no anchor to IEEE 60559.

The operative exclusion from the proposed [expr.const] wording is:

any operand is a signaling NaN, or the result is not mathematically defined in the domain of real number arithmetic

I understand what it means in context. I suspect CWG reviewers will too. But “domain of real number arithmetic” is informal vocabulary and a future DR will hit it and have to reverse-engineer the intent from the paper’s examples.

The underflow treatment deserves more attention. The paper proposes that underflow — producing a denormal or zero — is well-defined and is a valid constant expression, even though it raises FE_UNDERFLOW. This is treated the same as FE_INEXACT (rounding) for constant-evaluation purposes. The paper openly admits this is “inconsistent with the rest of the design” but justifies it on pragmatic grounds: no major compiler diagnoses underflow in constexpr today.

Honest concession, probably the right call, but it means the “constant expression ↔ no floating-point exceptions raised” model has a deliberate hole. The new well-definedness guarantee for overflow says:

if the type has an infinity representation, the result of the operation shall be +∞ or −∞

Underflow has no analogous clean statement. It’s just “this won’t disqualify the expression.” If you write code that checks fegetexcept after a constexpr init, you need to know this.

For those who want the backstory:

CWG2168 (~2016): CWG has an open question about whether FP overflow is UB on IEEE 754 types. They ask SG6. SG6’s guidance: overflow to infinity is well-defined at runtime; infinity should not be usable as a constant-expression subexpression. Filed and parked.

CWG2723 (later): Adds a definition of “range of representable values” for floating-point. No SG6 consultation. The definition doesn’t carve out ±∞ — effectively reverting SG6’s guidance and making overflow UB again.

Result: two DR issues pointing in opposite directions, three compilers making different choices, and a standard that can’t answer “is FLT_MAX * 2.0f undefined behavior?” without hedging.

P3899R1 untangles it. The partial deviation from the 2016 SG6 guidance — now allowing infinity propagation in constexpr — is deliberate. The original concern doesn’t hold as strongly under the current constexpr evaluation model.

One thing that jumps out: this paper is routed to SG6, then EWG, then CWG. Three groups, three sets of polls, plausibly spanning 2–3 meetings. For what is essentially a contradiction between two existing DRs. GCC 15 already does the right thing. By the time this is officially normative it will have been de facto standard for years. The committee process is thorough. Whether it is appropriately fast for correctness fixes is a separate question.

If you want to see the current behavioral gap: https://godbolt.org/z/K3vxYaE89

UBSAN reports FLT_MAX * 2.0f as floating-point overflow under -fsanitize=undefined. After this paper, that specific case becomes well-defined on IEEE 754 implementations and UBSAN should stop flagging it at runtime. 1.0f / 0.0f would still trigger.

#include <float.h>
int main() {
    volatile float x = FLT_MAX;
    float y = x * 2.0f;  // UBSAN: value outside representable range
    return y > 0 ? 1 : 0; // returns 1: infinity > 0
}

The fix is in the standard, not in UBSAN — toolchain updates will follow once the wording lands.

Wait so after this paper 1.0f / 0.0f is still UB? I thought the whole point was IEEE 754 conformance. Edit: ok I read section 4.3, the authors explain the signed-infinity and negative-zero edge cases. I was wrong. Edit2: still annoyed. 1.0f / 0.0f should just be +inf on any IEEE 754 type and everyone knows it.