Re: Interval aggregate regression failure (expected seems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paesold <mpaesold(at)gmx(dot)at>
Cc: Michael Glaesemann <grzm(at)myrealbox(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Interval aggregate regression failure (expected seems
Date: 2005-11-07 17:07:27
Message-ID: 20170.1131383247@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

I wrote:
> Michael Paesold <mpaesold(at)gmx(dot)at> writes:
>> I am definatly not going to use -march=pentium4 in any production
>> system. Should I open a bug report with RedHat (gcc vendor)?

> Yeah, but they'll probably want a smaller test case than "Postgres fails
> its regression tests" :-(

I have just confirmed that the problem still exists in FC4's current
compiler (gcc 4.0.1, gcc-4.0.1-4.fc4), which probably will boost up the
priority of the complaint quite a long way in Red Hat's eyes.

I've also confirmed that the problem is in interval_div; you can
reproduce the failure with

select '41 years 1 mon 11 days'::interval / 10;

which should give '4 years 1 mon 9 days 26:24:00', but when
timestamp.o is compiled with "-mcpu=pentium4 -march=pentium4",
you get '4 years 1 mon 10 days 02:24:00'. --enable-integer-datetimes
is not relevant because the interesting part is all double/integer
arithmetic.

Looking at this, though, I wonder if the pentium4 answer isn't "more
correct". If I'm doing the math by hand correctly, what we end up
with is having to cascade 3/10ths of a month down into the days field,
and since the conversion factor is supposed to be 30 days/month, that
should be exactly 9 days. Plus the one full day from the 11/10 days
gives 10 days. I think what is happening on all the non-Pentium
platforms is that (3.0/10.0)*30.0 is producing something just a shade
less than 9.0, whereas the Pentium gives 9.0 or a shade over, possibly
due to rearrangement of the calculation. I think we can still file this
as a compiler bug, because I'm pretty sure the C spec does not allow
rearrangement of floating-point calculations ... but we might want to
think about tweaking the code's roundoff behavior just a bit.

An example that's a little easier to look at is

select '41 years 1 mon'::interval / 10;

I get '4 years 1 mon 9 days' with the pentium4 optimization, and
'4 years 1 mon 8 days 24:00:00' without, and the former seems more
correct...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2005-11-07 17:37:17 Re: parameterized limit statements
Previous Message Marc G. Fournier 2005-11-07 17:02:11 Re: Old interfaces directory in CVS tree?

Browse pgsql-patches by date

  From Date Subject
Next Message Greg Stark 2005-11-07 19:22:37 Re: Interval aggregate regression failure (expected seems
Previous Message Tom Lane 2005-11-07 16:24:31 Re: return can contains any row or record functions