Robert Haas <robertmh...@gmail.com> writes: > On Wed, Dec 14, 2011 at 11:14 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> -ffloat-store is a brute force solution, I think, and would affect old >> versions of gcc that don't exhibit any problems. I would suggest >> altering configure to see whether the compiler recognizes >> -fexcess-precision=standard and adding that to CFLAGS if so.
> Would it be better to change either the code or the test case to be > less sensitive to this issue? AFAICS it's really impractical to do that. The code Andrew is having problems with is essentially double a,b,c; ... a = b * c; if (isinf(a)) throw error; and the problem is that the multiplication result overflows in double precision, but not in the wider-than-double register precision. Therefore, if a is in a register and the isinf() primitive inspects the register, it will return false, even though when the value gets stored to memory it will become an infinity. I don't see anything we can do to the code that avoids this issue. You might think that explicitly casting b * c to double would help, but our experiments in connection with the planner Assert case proved it didn't. The only other thing we could possibly do is move the multiplication into a separate subroutine, but what's to stop the compiler from inlining that and generating the same code anyway? Basically, what's going on here is that the gcc boys have decided that speed trumps both sanity and conformance to the letter of the C standard, unless you turn on compiler switches that say "please act sane". So we'd better do that, unless you'd like to be dealing with this type of issue for the rest of the project's lifespan. It's much the same type of problem as with -fno-strict-aliasing, except that someday we might consider biting the bullet and dealing with that piece of insanity-in-the-name-of-speed. Floating-point performance is not interesting enough for Postgres' purposes that I can imagine that we'd ever want to deal with this kind of gotcha to improve FP speed. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers