Re: Add support for AT LOCAL - Mailing list pgsql-hackers

On Tue, Oct 17, 2023 at 7:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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™.
>
> Discounting the Windows animals, it looks like the xlc animals are
> our only remaining ones that use anything except gcc or clang.
> That feels uncomfortably like a compiler monoculture to me, so
> I can understand the reasoning for keeping hornet/mandrill going.
> Still, maybe we should just accept the fact that gcc/clang have
> outcompeted everything else in the C compiler universe.  It's
> getting hard to imagine that anyone would bring out some new product
> that didn't try to be bug-compatible with gcc, for precisely the
> reason you mention.

After some research I determined that the release date for xlc 12.1
seems to be June 1, 2012. At that time, clang 3.1 was current and just
after, GCC release version 4.7.1 was released. The oldest version of
clang that I find in the buildfarm is 3.9, and the oldest version of
gcc I find in the buildfarm is 4.6.3. So, somewhat to my surprise, xlc
is not the oldest compiler that we're still supporting in the
buildfarm. But it is very old, and it seems like that gcc and clang
are going to continue to gain ground against gcc and other proprietary
compilers for some time to come. I think it's reasonable to ask
ourselves whether we really want to go to the trouble of maintaining
something that is likely to get so little real-world usage.

To be honest, I'm not particularly concerned about the need to adjust
compiler and linker options from time to time, even though I know that
probably annoys Andres. What does concern me is finding and coding
around compiler bugs. 19fa977311b9da9c6c84f0108600e78213751a38 is just
ridiculous, IMHO. If an end-of-life compiler for an end-of-life
operating system has bugs that mean that C code that's doing nothing
more than a bit of arithmetic isn't compiling properly, it's time to
pull the plug. Nor is this the first example of working around a bug
that only manifests in ancient xlc.

I think that, when there was more real diversity in the software
ecosystem, testing on a lot of platforms was a good way of finding out
whether you'd done something that was in general correct or just
something that happened to work on the machine you had in front of
you. But hornet and mandrill are not telling us about things we've
done that are incorrect in general yet happen to work on gcc and
clang. What they seem to be telling us about, in this case and some
others, are things that are CORRECT in general yet happen NOT to work
on ancient xlc. And that's an important difference, because if we were
finding real mistakes for which other platforms were not punishing us,
then we could hope that fixing those mistakes would improve
compatibility with other, equally niche platforms, potentially
including future platforms that haven't come along yet. As it is, it's
hard to believe that any work we put into this is going to have any
benefit on any system other than ancient AIX. If there are other niche
systems out there that have a similar number of bugs, they'll probably
be *different* bugs.

Sources for release dates:

https://www.ibm.com/support/pages/fix-list-xl-c-aix
https://releases.llvm.org/
https://gcc.gnu.org/releases.html

--
Robert Haas
EDB: http://www.enterprisedb.com