Fwiw it looks like the LLVM folk think this is an asan bug.
https://llvm.org/bugs/show_bug.cgi?id=25550
It looks like the fix is that the compiler should avoid this
optimization if the code is being compiled with instrumentation. This
worries me a bit but I think our code is safe as the Datum wil
Greg Stark writes:
> On Thu, Nov 12, 2015 at 3:51 PM, Tom Lane wrote:
>> I think we could fix the immediate issue by redeclaring numeric
>> headers as arrays of (u)int16 rather than structs. I'm not
>> very excited about the packed-header case.
> That would require giving up the pretense that t
On Thu, Nov 12, 2015 at 3:51 PM, Tom Lane wrote:
> Meh. The palloc to create an aligned array of digits would eat up
> any possible performance win --- it'd be just about as expensive
> as the existing unpack operation.
I suppose we would only need to palloc the digits if we found they
were unal
Greg Stark writes:
> On Thu, Nov 12, 2015 at 2:39 PM, Tom Lane wrote:
>> Either that's a reportable compiler bug, or someplace nearby we've
>> casted the pointer to something that would require a 4-byte struct.
>> I'm not sure which code you're looking at exactly, but maybe we're
>> using "union
On Thu, Nov 12, 2015 at 2:39 PM, Tom Lane wrote:
> Either that's a reportable compiler bug, or someplace nearby we've
> casted the pointer to something that would require a 4-byte struct.
> I'm not sure which code you're looking at exactly, but maybe we're
> using "union NumericChoice" prematurely
Greg Stark writes:
> In numeric.c we have the short numeric headers that have one uint16
> (in addition to the varlena header) followed by digits. When compiling
> with -O2 on x86-64 LLVM now seems to use a 4-byte access.
Either that's a reportable compiler bug, or someplace nearby we've
casted t
I've been using LLVM's sanitizers and asan turned up a new bit of
compiler behaviour that I hadn't had before. I don't see it in 3.7 or
before, only in their HEAD so I don't know if it's a bug or
intentional.
In numeric.c we have the short numeric headers that have one uint16
(in addition to the v
