Re: [HACKERS] problem compiling with egcs 1.1.1 - Mailing list pgsql-hackers

From Anthony Heading
Subject Re: [HACKERS] problem compiling with egcs 1.1.1
Date
Msg-id 19981214124839.A4469@sin-emstar1.ny.jpmorgan.com
Whole thread Raw
In response to Re: [HACKERS] problem compiling with egcs 1.1.1  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
Responses Re: [HACKERS] problem compiling with egcs 1.1.1  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
On Wed, Dec 09, 1998 at 05:58:39PM +0000, Thomas G. Lockhart wrote:
> In my limited testing, the only variable was the compiler. I did not
> change the C library. So, one can point fingers at the compiler for not
> behaving the same as the old compiler, or one can surmise that there is
> a deeper story of older C library misbehavior which was covered up by
> the older compiler in a great conspiracy. I leaned toward blaming the
> compiler, on the assumption that for most simple math compilers probably
> generate inline code rather than going to a library. It may be that for
> any compiler at high optimization levels you tend to see rounding
> problems since they don't bother cleaning up results.

FWIW, I understand this to be a problem mostly on the x86 architecture, 
where the floating point registers have higher precision than memory
storage.  Thus the results are somewhat unpredictable, depending on whether
registers are spilled into memory.  The -ffloat-store will help with
explictly named variables, but not temporary intermediate results.

While the egcs people may find a nice fix (the whole register spilling
issue is being worked on), apparently the C standard is very clear that
the .9999 behaviour is allowed.  So perhaps fixing the postgres code is
the best idea in the long run.

Anthony


pgsql-hackers by date:

Previous
From: Terry Mackintosh
Date:
Subject: Re: [HACKERS] 6.4.1 contrib/spi/
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] 6.4.1 contrib/spi/