On Thu, Nov 20, 2025 at 12:23 AM Peter Eisentraut <[email protected]> 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½ 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
