From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Sofer, Yuval" <Yuval_Sofer(at)bmc(dot)com> |
Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] compilation test fails |
Date: | 2009-05-21 14:30:35 |
Message-ID: | 10410.1242916235@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-general |
"Sofer, Yuval" <Yuval_Sofer(at)bmc(dot)com> writes:
> I have compiled 8.3.7 on HP-Itanium
> After the build I have continued to the tests (gmake check)
> One of the tests failed (division by zero error test)
Hm, what compiler and what optimization level? We have seen a report
or two about this before, all from people using gcc on non-mainstream
architectures. So far as I can tell it's a compiler bug. The code
in int84div looks like
int64 arg1 = PG_GETARG_INT64(0);
int32 arg2 = PG_GETARG_INT32(1);
int64 result;
if (arg2 == 0)
ereport(ERROR,
(errcode(ERRCODE_DIVISION_BY_ZERO),
errmsg("division by zero")));
result = arg1 / arg2;
and the only way to get the behavior you're showing is if the division
is executing (and causing a trap) before control is passed to ereport().
So apparently the compiler is forgetting that division can have a side
effect (ie machine trap) and thinking it's safe to reorder the
operations.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Duan Ligong | 2009-05-22 01:48:19 | cascade deleting |
Previous Message | Arnold, Sandra | 2009-05-21 14:29:05 | Re: Audit Log Destination |
From | Date | Subject | |
---|---|---|---|
Next Message | Kenneth Tilton | 2009-05-21 16:35:49 | Postgres, DB design, and object IDs (of any ilk) |
Previous Message | Grzegorz Jaśkiewicz | 2009-05-21 14:02:57 | Re: fsm on 8.1 |