Skip site navigation (1) Skip section navigation (2)

Re: GIST code doesn't build on strict 64-bit machines

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: GIST code doesn't build on strict 64-bit machines
Date: 2004-03-29 15:17:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> But all of this is strage for me, because we already faced to problem with 
> 8-bytes strict aliasing in GiST code, and we had resolved problem on Sun and 
> Alpha boxes. What was it changed?

It looks to me like the HP compiler is expecting that the constant
offset part of a doubleword load or store instruction should be a
multiple of 8.  The offset-the-evec hack you're using falls foul of
that even though the ultimate runtime address would be legal.  I'm
not sure whether this is a constraint of the actual HPPA instruction
format, or just overly anal compile-time testing.  gcc doesn't seem
to have a problem, but it's quite possibly not generating the most
efficient instruction sequence, either.

>> I suppose that a correct fix involves doing MAXALIGN(VARDATA(evec)),
>> but I do not know what places need to change to support this.

> Its only union and picksplit user-defined methods in contrib modules.

If I recall correctly, we decided to go with the present hack because we
found the problem just before a release date and there wasn't time to do
it more cleanly.  It seems to me that there is time to fix it right for
7.5 ... 

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2004-03-29 15:29:26
Subject: Re: Fuzzy cost comparison to eliminate redundant planning
Previous:From: Chris BowlbyDate: 2004-03-29 15:07:44
Subject: Row sampling..

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group