Hacker News Reader

Hacker News

Comment by amluto | Hacker News Reader

Parent Full thread

amluto

Your timeline is missing:

2012: I file the obvious bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522

Early 2023: bug is fixed.

Feb 2024: clang follows suit:

https://github.com/llvm/llvm-project/pull/80475

And maybe later this year this problem will finally be gone in common Linux distros.

View on HN

I don't want to read through 11 years of comments, but what does observable effects does corrupting mxcsr have? Surely it's just enabling FTZ/DAZ mode for the FPU which could harm bit-exactness in floating point math... but in code that cares about it, it's not uncommon to see RAII guards to configure the behavior you want (and usually, it's desirable to not comply with IEEE754 w.r.t subnormal numbers).

Like it's a quirk that floating point math can be non-deterministic but how bad is it, and is it actually a bug?

I think the biggest thing is that programmers can safely assume that a floating point `x-y` is nonzero if `x != y`. You can actually go farther and know that it's an exact computation (with no error) if the two are close [1]. But both results only hold if subnormals don't flush to or behave like zero.

It's not too hard to imagine how an algorithm might depend upon that — there could be a branch for the case where `x == y` and then a branch that relies upon dividing by `(x-y)` and assumes that it's not a division by zero.

1. https://en.wikipedia.org/wiki/Sterbenz_lemma

I don't think an algorithm that relies on this is particularly well designed. Anything that trusts a float is non-zero is probably some kind of division where you must avoid division by zero. In that case you should explicitly checking for the zero condition instead of relying on the semantics of real numbers, since floats are not real numbers.

That’s precisely the misapprehension that makes folks think that -ffast-math is fine. Each and every floating point number is an exact quantity. They are real mathematical objects that identify exact values. They just have limited precision and might round (think snap) to the nearest representable number after each computation. You might not use them that way, but it doesn’t mean others shouldn’t.

For example, floating point without can represent two numbers whose difference is smaller than the number can represent and rounds to zero. Subnormal floating point doesn't fix this, it just moves the impacts of underflow to smaller magnitudes that are less likely to be seen.

Look, -ffast-math isn't always fine, but specifically I'm looking at DAZ/FTZ enabled, possibly non-deterministically process-wide (which is bad, don't get me wrong!). But part of why this doesn't phase people is because in practice, programs don't care and the observable effects don't lead to bugs.

> floating point without can represent two numbers whose difference is smaller than the number can represent and rounds to zero

Did you intend to say "without FTZ/DAZ enabled"? If so, that's completely and provenly false.

https://en.wikipedia.org/wiki/Sterbenz_lemma

Perhaps a better example than `z/(x-y)` is `log(x-y)`. Unlike division by 0.0, `log(0.0)` often throws an immediate error whereas `log(5e-324)` is a finite — and meaningful! — result.

Wouldn't the compiler optimize (x-y)!=0 to x!=y? Seems like a good optimisation to me and one probably in accordance to the C standard.

It would also make it impossible to have a decent non-zero check for

if ((x-y)!=0) progress((x-t)/(x-y));

Plenty of OSS authors are contributing from work, so there's a good chance they're running LTS distros. Give it another few years for those to get updated.

Reply on news.ycombinator.com