Something in our JIT code is screwing up PG_PRINTF_ATTRIBUTE

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=]
234 | #define pg_attribute_printf(f,a) __attribute__((format(PG_PRINTF_ATTRIBUTE, f, a)))
| ^
../../../../src/include/port.h:233:86: note: in expansion of macro 'pg_attribute_printf'
233 | extern int pg_vsnprintf(char *str, size_t count, const char *fmt, va_list args) pg_attribute_printf(3, 0);
| ^~~~~~~~~~~~~~~~~~~

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.

There are at least two things that seem wrong here:

1. The affected platforms are CentOS Stream 9, CentOS Stream 10, and
AlmaLinux 10.0 (so it's not exactly old obsolete stuff). Since those
are all Linux variants, what we *should* be choosing is "gnu_printf",
yet the configure log shows we chose "__syslog__". Why?

2. Something in the LLVM headers on those platforms has evidently
decided that it'd be a brilliant idea to #define "__syslog__" as
"syslog", and that's breaking this. That seems jaw-droppingly
stupid; why'd they do that, and what can we do to work around it?

Presumably, this is breaking the compiler's ability to check format
strings, so it's not cool to just ignore it.

Adding to my confusion, I do not see these warnings on a local
RHEL9 machine, which ought to be pretty equivalent to CentOS 9.

Anybody want to look into this more closely?

regards, tom lane