Peter Eisentraut <pete...@gmx.net> writes: > On 04/21/2016 08:18 PM, Tom Lane wrote: >> Could you send along the assembler code generated by the compiler (-S >> output) for float.c? Maybe that would shed some light. Probably the >> -O0 version would be easier to read.
> Attached is a smaller test program that prints 29.9999999999999964 (same > as failing test result) as well as its assembler code. This doesn't prove much. It's clear from the assembly code that the compiler is evaluating "asin(0.5)" at compile time (and, presumably, getting a different answer than would be produced at runtime). But that's entirely unsurprising given this source text: you've got a naked application of asin() to a constant. What we need to know, and what this doesn't quite prove, is whether the compiler is managing to see through the tricks that float.c uses to prevent compile-time calculation of that value. The fact that this produces the same number as we see in the regression test does point to the idea that that's what's happening. But it's not conclusive. Part of the reason I'm not sold is that even if the compiler can see through those tricks when optimizing, it hardly seems like it should do so at -O0. If that is the answer, then the next question is how we can put more roadblocks in the way of compile-time evaluation of asin(0.5). Dean suggested that creative use of "volatile" might do it, and I agree that that sounds like a promising thing to pursue. 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