"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> Alvaro Herrera wrote:
>> Stefan showed me via Jabber this warning:
>>
>> /tmp/ccM7MfqX.s: Assembler messages:
>> /tmp/ccM7MfqX.s:703: Warning: 00000003fffffffc shortened to 00000000fffffffc
>> /tmp/ccM7MfqX.s:738: Warning: 00000003fffffffc shortened to 00000000fffffffc
>>
>> He says that this comes from trgm_op.c file. I don't get the warning
>> myself obviously, so I started guessing.
I've occasionally seen this warning too. It seems to be pretty random though.
Nor have I been able to find any actual problems caused by it.
But istm this has to be a compiler bug since any overflow in the C code should
be handled (and potentially warned) by the compiler long before the assembler
gets to see it.
>> So the upper 2 bits are being lost (the second number is 32 bits wide).
>>
>> The only thing that I think is related is the usage of VARSIZE(). It
>> looks like 0x3FFFFFFF (actual constant in the toast code) is shift two
>> bits left. I can see no such operation though.
>
> The shift is in postgres.h, SET_VARSIZE_4B. I have no idea where that warning is
> coming from, though. What's the real source behind "ccM7MfqX.s"?
Huh. I wonder.
Could the compiler be incorrectly optimizing cases of
SET_VARSIZE(new_datum VARSIZE(olddatum))
which amounts to:
((olddatum >> 2) & 0x3FFFFFFF) << 2
If it does constant propagation without handling overflow it could end up
with:
(olddatum >> 2 << 2) & 0x3FFFFFFFC
note that in fact truncating the high two bits as the assembler did would in
fact be the correct thing to do here which would explain why it doesn't cause
any actual problems.
Also note that it doesn't require an actual single statement of the form
above. The compiler could be doing constant propagation from an earlier
statement. Code which calls VARSIZE(olddatum) and then passes the result to
SET_VARSIZE(newdatum,len) is quite common.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
