MIME-Version: 1.0
References: 
 <CA+hUKGKFvu3zyvv3aaj5hHs9VtWcjFAmisOwOc7aOZNc5AF3NA@mail.gmail.com>
 <536409d2-c9df-4ef3-808d-1ffc3182868c@iki.fi>
 <CA+hUKG+bub1T9TFLUAJHr+Z519VRgJS5tb10xBxEtJZRH8GXiA@mail.gmail.com>
 <94c83f24-43cb-4a8b-b09b-42bd85ed7d65@eisentraut.org>
In-Reply-To: <94c83f24-43cb-4a8b-b09b-42bd85ed7d65@eisentraut.org>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Thu, 20 Nov 2025 20:12:18 +1300
Message-ID: 
 <CA+hUKGKfNuXYVKT7WPpKTNYTgPduzu0=G5yFEMju_4kbW0ybOQ@mail.gmail.com>
Subject: Re: Trying out <stdatomic.h>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BhUKGKfNuXYVKT7WPpKTNYTgPduzu0%3DG5yFEMju_4kbW0ybOQ%40mail.gmail.com>
Precedence: bulk

On Thu, Nov 20, 2025 at 12:23=E2=80=AFAM Peter Eisentraut <peter@eisentraut=
.org> wrote:
> On 13.11.25 12:35, Thomas Munro wrote:
> > It passes with VS 2022 on CI.  I had to skip some assertions about
> > macros promising lock-free implementation, that it doesn't define in C
> > mode yet.  They are definitely lock-free though[1], and the macros are
> > defined for C++, and the same under the covers...  Perhaps
> > feature/conformance macros won't be defined until a few remaining
> > pieces (things we don't care about) are accessible from C?  (I see
> > that Visual Studio 2026 has also just shipped a couple of days ago,
> > not investigated.)
>
> Note also that we still have buildfarm members with gcc <4.9, which is
> required for stdatomic.h/_Atomic there.

Those are EOL'd RHEL/Centos 7 and SUSE 12 systems.  A decision to
require GCC 4.9+ might not be fatal to them though, as those distros
had optional newer tool chain packages too.  I'm not sure what
problems could follow from that, probably not much as far as C goes?
C++ ABI questions are always harder but such old systems couldn't
possibly use LLVM as we chop old releases based on distro EOL dates,
and LLVM adopts new language standards (being a compiler project after
all).  (It'll be interesting to see what happens when LLVM requires
C++23, and then RHEL's new rolling LLVM upgrade policy meets its 10
year old stable compiler policy...)

The elephant in the room is Visual Studio.  We have drongo on 2019,
hammerkop on 2022, and CI on 2019 but ready to flip to 2022 whenever
we're ready.  There is no testing for 2026, being only a few days old
(I heard from Bilal that our CI passed when he tried it out FWIW).
2019 fell out of "mainstream" support 1.6 years ago[1], "extended"
support lasts 3.4 more years, and 2017's "extended" support also lasts
1.4 more years, which didn't stop commit 8fd9bb1d from chopping it to
gain some C11 support.  When could we chop 2019 too, to gain more C11
support?

What motivation do people have to use old compilers for new software?
If my google-search-fu is serving me, upgrades are either free
(community edition for individuals, also for organisations working on
open source) or included in various paid subscriptions.  Is there a
technical reason to be more conservative, for example, in terms of
library versions on the target system, something to do with UCRT or
_WIN32_WINNT versions that the EDB installer needs to target before
you can use this stuff?  I can't find anything saying so.  Perhaps
it'd be better to wait until /experimental:c11atomics isn't needed
though.  My impression so far is that that's about conformance with
details we don't care about, not the maturity of the codegen which is
used far and wide in C++, it's just that C conformance is a distant
second priority (1=C2=BD decades later), but...  (Not that this project is
finished anyway, more study and validation required.)

[1] https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2019