Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Dec 14, 2011 at 11:14 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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