https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116331
--- Comment #3 from Carl Dehlin <carl at dehlin dot com> --- Thanks Andrew for your quick response and confirmation of what is going on. After reading through all the excessive precision stuff I was so sure this related to it! Very interesting to see that floating point operations can be non-deterministic in so many ways! Funny thing is that this reduced test fails in a different way from my real test case, which certainly does not fail due to constant folding (if you wonder where I got my magic constant from, the answer is pure randomness!). Still prepping a bug report for that, but struggling with reducing it without triggering this again. I agree, 1 ulp is not very significant, and impressive considering that there are two separate implementations computing almost the same value. The fact that the standard is pushing for constexpr implementations of the math library, does that mean that it will merge into the compiler front end soon? It seems difficult to maintain two separate implementations that most people will expect to work identical. I still think the behavior is very surprising though. I will not attempt to convince anyone that it is a true bug, I'm sure there is a place in the standard somewhere saying that the compiler is allowed to substitute standard library calls to builtin functions with slightly different behavior, and that compile time eval does not have to be bit exact with run time eval. But, I do believe if it is not resolved in some way it might turn into another 323 as more people start to do crazy constexpr stuff with math functions. So I think it is in everyone's interest, both gcc users and devs, to discuss this a bit more. Questions ========= 1) What benefits does __builtin_cos (i.e. constexpr cos), bring over the library version? If the point of the builtin is just to provide constexpr alternative, then I can just turn all builtin math off and get on with my life. If there are other benefits, then I need to consider them 2) Would it make sense to not promote constant literals produced by math library functions, such that they are only used in explicitly declared constexpr contexts? This depends on the answer to my first question ofc. I think it would reduce future bugs related to constant folding of floating point expressions. 3) Now 1 ulp is not much, but it might also be completely co-incidental, we wouldn't know if there are worse cases without scanning all doubles right? Should one replace == with a typical abs(x-y) < eps sort of thing to handle this? In that case, what should eps be? Everything turns complicated once the == is broken, but I am happy to hear more about this and how to properly approach it, perhaps there are guarantees from GCC, or from the C++ standard itself even. Cheers, / Carl
