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: 914.1080573426@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

Responses

Browse pgsql-hackers by date

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