gcc-15-20250216 is now available
Snapshot gcc-15-20250216 is now available on https://gcc.gnu.org/pub/gcc/snapshots/15-20250216/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 15 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 68e74199c61c5ad81ffe37e41cd62d0d7415b3ab You'll find: gcc-15-20250216.tar.xz Complete GCC SHA256=072688e30a90d6896493a239e768d7c5cac2fdeaa19f2047e8f86082857a1aaf SHA1=66d16f77e338943cbf8ec65d4341d03789a98e89 Diffs from 15-20250209 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-15 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Classes Implicitly Declared
Ugh, sorry. the lack of Subject/References broke threading and I missed this continuation. On Wed, Feb 12, 2025 at 22:46:23 +, Frederick Virchanza Gotham via Gcc wrote: > I think it might be a possibility given how compiler vendors (and also > vendors of tools like CMake) aren't really getting very far with > modules. They've had a few years already. "Not very far" is probably the opinion of someone that last seriously checked in on the status in 2021 or so. Things have definitely changed since then. Yes, it has taken time. Longer than I'd like (as author of the CMake support, author of P1689 for dependency scanning, and SG15 Tooling member). But writing a spec to have toolchains to make what build systems need to get what users need to test toolchains is not a fast iteration cycle. Rinse and repeat for `import std`. It will likely be another run through this cycle for header units too. But we are finally at a point where named modules can be experimented with. The timeline has been (roughly): - 2019 Feb: pushing to get dependency scanning possible (I have patches to CMake and GCC to proof-of-concept at the Kona meeting) - 2019 Mar: CMake uses P1689R2 for its Fortran scanning/dependency computations. The implementation is updated for further revision updates as time goes on. - 2020-2022: hammering out P1689 details. As of P1689R5 it is in a place where everyone is happy. Alas, my allocations did not align with faster progress here. - 2022 Jun: experimental support for named modules lands in CMake 3.25. Community and toolchain implementers experiment with my GCC patches and report issues. - 2023 Sep: my P1689R5 patches land in GCC - 2023 Oct: CMake 3.28 releases with named imports as a non-experimental feature - 2022 Nov: VS 17.4 releases with P1689 support - 2023 Feb: clang-scan-deps learns to write P1689R5 - 2024 Apr: Support for clang/libc++ and MSVC/STL `import std;` lands in CMake `master` - 2024 Jul: Experimental support for `import std;` in CMake 3.30. - 2024 Nov: Support for GCC's `import std;` lands We're now at a point where *projects* can experiment with modules meaningfully (via CMake at least). I hope this drives finding issues both with CMake (of which I'm aware of a number) and toolchains (of which I'm sure there is some awareness of their existence, but prioritizing them may be hard without user feedback). I've also been working to help drive adoption in other build systems: Bazel: experimental community-driven support (though Google needed some convincing to allow the community to experiment with it) Meson: interest, but no progress AFAIK Tup: *crickets* xmake: done Progress in others that I have not contacted directly about it: autotools: didn't have a maintainer when I did the first round, but zackw has since picked it up…I should reach out MSBuild: done (though its developers were present for P1689 discussions) So as long as you're using CMake or xmake, go forth and test. Please file issues too. Thanks, --Ben
Re: Classes Implicitly Declared
On Sun, Feb 16, 2025 at 22:59:45 +0100, Ben Boeckel wrote: > But we are finally at a point where named modules can be experimented > with. The timeline has been (roughly): > > - 2019 Feb: pushing to get dependency scanning possible (I have patches > to CMake and GCC to proof-of-concept at the Kona meeting) > - 2019 Mar: CMake uses P1689R2 for its Fortran scanning/dependency > computations. The implementation is updated for further revision > updates as time goes on. Sorry, I missed some entries here: - 2019 Apr: Patches to `ninja` land to support `dyndep` (needed for accurate C++ dependency scanning) - 2020 Jan: `ninja` 1.10 releases with `dyndep` support > - 2020-2022: hammering out P1689 details. As of P1689R5 it is in a place > where everyone is happy. Alas, my allocations did not align with > faster progress here. > - 2022 Jun: experimental support for named modules lands in CMake 3.25. > Community and toolchain implementers experiment with my GCC patches > and report issues. > - 2023 Sep: my P1689R5 patches land in GCC > - 2023 Oct: CMake 3.28 releases with named imports as a non-experimental > feature > - 2022 Nov: VS 17.4 releases with P1689 support > - 2023 Feb: clang-scan-deps learns to write P1689R5 > - 2024 Apr: Support for clang/libc++ and MSVC/STL `import std;` lands in > CMake `master` > - 2024 Jul: Experimental support for `import std;` in CMake 3.30. > - 2024 Nov: Support for GCC's `import std;` lands --Ben
Commits not appearing in bugzilla
My commits have not been appearing in bugzilla for quite some time now. Some recent examples have been https://gcc.gnu.org/pipermail/gcc-cvs/2025-February/417177.html https://gcc.gnu.org/pipermail/gcc-cvs/2025-February/417426.html Is this a misconfiguration somewhere? Should I be doing something different? (Incidentally, the mailing system messes up the UTF-8 represntation of my last name, König, maybe that is somehing to do with it). Best regards Thomas
Re: Commits not appearing in bugzilla
Thomas Koenig via Gcc writes: > (Incidentally, the mailing system messes up the UTF-8 represntation > of my last name, König, maybe that is somehing to do with it). IIRC my commits were failing to go through due to the presence of a "ć" in my /etc/passwd entry on Sourceware. This might be the same thing. I don't know why it is an issue, though. -- Arsen Arsenović signature.asc Description: PGP signature
Re: Commits not appearing in bugzilla
Am 16.02.25 um 17:59 schrieb Thomas Koenig: Am 16.02.25 um 16:29 schrieb Mark Wielaard: For now I replaced Thomas last name with just "Koenig". Hope that resolve the issue. Thanks! We'll see with the next commit. ... which worked, so the non-ASCII letters in the name seems to have been the problem. Again, thanks for fixing this! Best regards Thomas
Re: Commits not appearing in bugzilla
Am 16.02.25 um 16:29 schrieb Mark Wielaard: For now I replaced Thomas last name with just "Koenig". Hope that resolve the issue. Thanks! We'll see with the next commit. Best regards Thomas
Re: Commits not appearing in bugzilla
Hi Thomas, Hi Arsen, On Sun, Feb 16, 2025 at 01:35:05PM +0100, Arsen Arsenović via Gcc wrote: > Thomas Koenig via Gcc writes: > > > (Incidentally, the mailing system messes up the UTF-8 represntation > > of my last name, König, maybe that is somehing to do with it). > > IIRC my commits were failing to go through due to the presence of a "ć" > in my /etc/passwd entry on Sourceware. This might be the same thing. > > I don't know why it is an issue, though. That might indeed be the issue. I believe the hook uses a python getent wrapper to retrieve the user name, which doesn't understand the encoding used. For now I replaced Thomas last name with just "Koenig". Hope that resolve the issue. It is a little embarrassing we still don't properly handle non-ascii encodings correctly. Apologies, Mark
Re: Modules deprecation rumors
On Wed, Feb 12, 2025 at 09:51:36 +, Frederick Virchanza Gotham via Gcc wrote: > This would be an alternative to modules (seeing as how modules might > become deprecated in the future). If this is the case, no one has informed the stakeholders in the C++ committee (SG2, EWG, SG15, likely many more) of this development, so whoever is rumormilling this probably has some axe to grind (or is upset at having to port their build system to support them). --Ben
