Re: Postgres storing time in strange manner

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Postgres storing time in strange manner
Дата
Msg-id 21086.1032242492@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Postgres storing time in strange manner  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Postgres storing time in strange manner  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Peter Eisentraut <peter_e@gmx.net> writes:
> If the test doesn't use any library function's run-time behavior, you can
> usually do something like

> main() {
> int a[(2.0+2.0==4.0)?1:-1]
> }

> This will fail to compile if the floating-point arithmetic is broken.

However, unless gcc itself is compiled with -ffast-math, such an
approach won't show up the bug.

I had success with this test:

#include <stdio.h>

double d18000 = 18000.0;

main() {
  int d = d18000 / 3600;
  printf("18000.0 / 3600 = %d\n", d);
  return 0;
}

Using Red Hat 7.2's compiler:

[tgl@rh1 tgl]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)

I get:

[tgl@rh1 tgl]$ gcc bug.c
[tgl@rh1 tgl]$ ./a.out
18000.0 / 3600 = 5            -- right
[tgl@rh1 tgl]$ gcc -ffast-math bug.c
[tgl@rh1 tgl]$ ./a.out
18000.0 / 3600 = 4            -- wrong!

You need the dummy global variable to keep the compiler from simplifying
the division at compile time, else you get 5.  With the test as
exhibited, the -O level seems not to matter.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: Bug #758: show_planner_stats does not work for new PREPARE calls
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Postgres storing time in strange manner