Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Oct 18, 2023 at 11:54 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Should we be testing against xlclang instead?
> I hesitated to suggest it because it's not my animal/time we're
> talking about but it seems to make more sense. It appears to be IBM's
> answer to the nothing-builds-with-this-thing phenomenon, since it
> accepts a lot of GCCisms via Clang's adoption of them. From a quick
> glance at [1], it lacks the atomics builtins but we have our own
> assembler magic for POWER. So maybe it'd all just work™.
FWIW, I tried a test build with xlclang 16.1 on cfarm111, and
it does seem like it Just Works, modulo a couple of oddities:
* <netinet/tcp.h> fails to compile, due to references to struct
in6_addr, unless <netinet/in.h> is included first. Most of our
references to tcp.h already do that, but not libpq-be.h and
fe-protocol3.c. I'm a bit at a loss why we've not seen this
with the existing BF animals on this machine, because AFAICS
they're all using the same /usr/include tree.
* configure recognizes this as gcc but not Clang, which may or may
not be fine:
...
checking whether we are using the GNU C compiler... yes
...
checking whether xlclang is Clang... no
...
This doesn't seem to break anything, but it struck me as odd.
configure seems to pick a sane set of compiler options anyway.
Interestingly, xlclang shows the same failure with the pre-19fa97731
versions of timetz_zone/timetz_izone as plain xlc does. I guess
this is not so astonishing since they presumably share the same
codegen backend. But maybe somebody ought to file a bug with IBM?
regards, tom lane