At 14:27 19.11.01 -0500, Tom Lane wrote:
>"Tegge, Bernd" <tegge(at)repas-aeg(dot)de> writes:
> > I've got a rather ugly but usable workaround. See attached timestamp.c
>My, that *is* ugly. Surely there's gotta be something cleaner.
>I don't quite understand how it is that the Compaq compiler works at
>all, if it thinks it can optimize random memcpy operations into
>opcodes that assume aligned addresses.
Well, if both operands are ptr to double and the compiler/runtime
system aligns doubles except on explicit request (frex #pragma noalign)
the optimizer probably thought it was safe to replace the memcpy by a
load/store double operation. It probably should not have done this
after casting the pointers to void*, but it did ...
> We should be coredumping in a
>lot more places than just this. Since we're not, there's got to be
>some fairly straightforward way of defeating the optimization.
>The extra memcpy looks to me like black magic that doesn't really have
>anything directly to do with the problem.
I had to use the temp vars after the assignment. Otherwise the compiler
optimized them away. Sometimes this thing is amazing.
>I'm surprised that the (void *) cast didn't fix it. Perhaps it would
>work to use DatumGetPointer rather than DatumGetIntervalP --- that is,
>never give the compiler any hint that the source might be considered
>double-aligned in the first place.
Thanks, *that* did it. We should just extend the comment block above
to going back to DatumGetIntervalP if the array code ever gets fixed.
In response to
pgsql-ports by date
|Next:||From: Tom Lane||Date: 2001-11-21 14:36:43|
|Subject: Re: Regression fails on Alpha True64 V5.0 for yesterdays cvs |
|Previous:||From: Tom Lane||Date: 2001-11-21 04:27:39|
|Subject: Re: Darwin/MacOSX 10.1.1 newbie |