Peter Eisentraut <peter_e@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