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
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.. |