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
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2004-03-29 15:29:26|
|Subject: Re: Fuzzy cost comparison to eliminate redundant planning |
|Previous:||From: Chris Bowlby||Date: 2004-03-29 15:07:44|
|Subject: Row sampling..|