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
|
Список | 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 по дате отправления: