Re: Something in our JIT code is screwing up PG_PRINTF_ATTRIBUTE

I wrote:
> Currently, configure tries "gnu_printf" then "__syslog__" then
> "printf" to set PG_PRINTF_ATTRIBUTE. Of late, buildfarm member
> fritillary has been issuing warnings like

> ../../../../src/include/c.h:234:83: warning: 'syslog' is an unrecognized format function type [-Wformat=]

> I hadn't gotten around to looking at that closely, but in the past
> week three new animals (borer, skeletonizer, whitefly) have started
> doing that too. On inspection, I realize that that's not happening
> across our entire tree, but only within src/backend/jit/llvm.

Okay, I've figured out what's going on here, and it's not really
a new problem. The proximate cause is that these four animals are
set up to explicitly pick clang:

'config_env' => {
'CC' => 'clang'
},

but they are not forcing the choice of C++ compiler, and configure
just defaults that to "g++".

Although clang claims to support the same format attributes as
gcc (in fact, its documentation merely refers you to gcc's docs),
that is a flat-out lie. It has never supported "gnu_printf".
It does support "__syslog__" ... which gcc doesn't, at least
on Linux, and never has.

Thus, what's happening is that configure chooses PG_PRINTF_ATTRIBUTE
based on what the CC compiler likes, and then when we build C++ code
with the CXX compiler, it complains.

So if we don't want to see these warnings, either we need to try
to use the C++ compiler matching the CC choice, or we need to make
PG_PRINTF_ATTRIBUTE language-sensitive. I think it should work
to do two configure probes and then make c.h do something like

#ifdef __cplusplus
#define PG_PRINTF_ATTRIBUTE PG_CPP_PRINTF_ATTRIBUTE
#else
#define PG_PRINTF_ATTRIBUTE PG_C_PRINTF_ATTRIBUTE
#endif

On the other hand, aligning the C++ compiler with the C compiler
is likely to avoid other problems, so maybe it's better to focus
on making that happen. I'm not sure how we'd do that automatically
though.

For the moment we could silence the buildfarm noise by pressing
Mark W. to fix the configurations on these BF animals, which
is surely a lot less work than finding an automatic solution.

Thoughts?

regards, tom lane