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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GIST code doesn't build on strict 64-bit machines
Дата
Msg-id 914.1080573426@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GIST code doesn't build on strict 64-bit machines  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: GIST code doesn't build on strict 64-bit machines  (Teodor Sigaev <teodor@sigaev.ru>)
Список pgsql-hackers
Teodor Sigaev <teodor@sigaev.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chris Bowlby
Дата:
Сообщение: Row sampling..
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Fuzzy cost comparison to eliminate redundant planning