Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> some more(I have removed duplicates and ones that should be fixed by
>> your latest commits though):
>
> I did what I could with this batch. Some comments:
>
>> animal: salamander warnings: 27
>> cash.c: In function `cash_in':
>> cash.c:244: warning: subscript has type `char'
>
> I wish we could promote this one to be a hard error :-(. It typically
> indicates (and did in this case) that someone has unportably forgotten
> to cast the argument of a <ctype.h> macro to unsigned char.
:-( we can promote certain warnings to an error on sun studio vor
example but salamander is running gcc ...
>
>> pg_lzcompress.c: In function `pglz_compress':
>> pg_lzcompress.c:378: warning: inlining failed in call to `pglz_find_match'
>
> This is not an error condition, it just means that gcc decided not to do
> inlining because the called function was too big. IIRC we had some
> discussion whether to specify -Winline or not, and decided to do so in
> order to gather some info about whether we were overstressing "inline".
> We could live with it as-is, or document somewhere (where?) that "it's
> fine as long as you don't see very many of 'em", or decide that the
> experiment is finished and we should take out -Winline. Comments?
we have about 5 boxes on the farm with that exact warning (inlining
failed in pglz_find_match) there are no other inline related warnings at
all afaiks.
>> animal: lionfish warnings: 16
>> /tmp/cclwN8N9.s: Assembler messages:
>> /tmp/cclwN8N9.s:109082: Warning: Macro instruction expanded into
>> multiple instructions
>> [multiple occurrences]
>
> This is pretty strange. It seems to occur only in files generated
> from bison and/or flex. Anybody have a clue?
other than that lionfish is a weird mips box - no :-)
Stefan
