On 26 April 2016 at 04:25, Tom Lane <t...@sss.pgh.pa.us> wrote: > In short, these tests suggest that we need a coding pattern like > this: > > volatile float8 asin_x = asin(x); > return (asin_x / asin_0_5) * 30.0; > > We could drop the "volatile" by adopting -ffloat-store, but that > doesn't seem like a better answer, because -ffloat-store would > pessimize a lot of code elsewhere. (It causes a whole lot of > changes in float.c, for sure.)
Agreed. That looks like the least hacky way of solving the problem. I think it's more readable when the logic is kept local, and it's preferable to avoid any compiler-specific options or global flags that would affect other code. 6b1a213bbd6599228b2b67f7552ff7cc378797bf by itself looks like a worthwhile improvement that ought to be more robust, even though it didn't fix this problem. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
