GCC 14.1.1 Status Report (2024-05-07)
Status == The GCC 14.1 release tarballs have been created, the releases/gcc-14 branch is open again for regression and documentation bugfixing. GCC 14.2 can be expected in about two months unless something serious changes the plans. Quality Data Priority # Change from last report --- --- P10 P2 605- 1 P3 72+ 15 P4 217- 2 P5 25 --- --- Total P1-P3 677+ 14 Total 919+ 12 Previous Report === https://gcc.gnu.org/pipermail/gcc/2024-April/243823.html
GCC 14.1 Released
The GCC developers are proud to announce a new major GCC release, 14.1. The C frontend when targeting standards newer than C89 now considers many non-standard constructs as errors that were previously only warnings. See https://gcc.gnu.org/gcc-14/porting_to.html#warnings-as-errors for more details. C23 _BitInt Bit-precise integer types are now supported, for now only on IA-32, x86-64 and AArch64. The C++ frontend now implements several C++26 features, some missing C++23 bits and defect report resolutions. Diagnostics involving C++ templates now quote source from the instantiation context. The libstdc++exp.a library now includes all symbols for the Filesystem TS and the experimental symbols for the C++23 std::stacktrace class, so -lstdc++exp can be used instead of -lstdc++fs. The libstdc++_libbacktrace.a library is not longer installed. Improved experimental support for C++20, C++23, and C++26. Updated parallel algorithms that are compatible with oneTBB. GCC now implements the Clang extensions __has_feature and __has_extension for the C family language frontends. The Fortran frontend now accepts -std=f2023 in preparation of support of Fortran 2023. GCC now has a new -fhardened flag to enable security hardening features available on the target platform. OpenMP and OpenACC offloading is made easier by no longer requiring explicit passing of -lm or -lgfortran to the offload device linker. The AMD GCN offload target gained support for select RDNA2 and RDNA3 graphics cards. The vectorizer can now vectorize loops which contain alternate exits such as via break statements and can now target RISC-V with a comparable feature set than other main architectures. The #pragma GCC novector pragma can be used to disable vectorization of annotated loops. GCC's Static Analyzer has been greatly improved, still mainly targeting C code. The AArch64 target supports new hardware features like SME and SME2 and can now handle GCCs function multiversioning. The IA-32/x86-64 target can now target AVX10.1 and APX supporting CPUs and can target recent and future announced CPU families. The LoongArch port got support for vector ISA extensions and the Ada and D frontends. The RISC-V port now enables SLP and loop vectorization when the vector extension is enabled and supports vector intrinsics as of the RVV 1.0 specification. Some code that compiled successfully with older GCC versions might require source changes, see http://gcc.gnu.org/gcc-14/porting_to.html for details. See https://gcc.gnu.org/gcc-14/changes.html for more information about changes in GCC 14.1. This release is available from the WWW and FTP servers listed here: https://sourceware.org/pub/gcc/releases/gcc-14.1.0/ https://gcc.gnu.org/mirrors.html The release is in the gcc-14.1.0/ subdirectory. If you encounter difficulties using GCC 14.1, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. Driving a leading free software project such as GCC would not be possible without support from its many contributors. Not only its developers, but especially its regular testers and users which contribute to its high quality. The list of individuals is too large to thank individually!
Re: Updated Sourceware infrastructure plans
On Thu, 2 May 2024, Fangrui Song wrote: > > On the other hand, GitHub structures the concept of pull requests > > around branches and enforces a branch-centric workflow. A pull request > > centers on the difference (commits) between the base branch and the > > feature branch. GitHub does not employ a stable identifier for commit > > tracking. If commits are rebased, reordered, or combined, GitHub can > > easily become confused. I'd say we have two kinds of patch submission (= two kinds of pull request in a pull request workflow) to consider in the toolchain, and it's important that a PR-based system supports both of them well (and supports a submission changing from one kind to the other, and preferably dependencies between multiple PRs where appropriate). * Simple submissions that are intended to end up as a single commit on the mainline (squash merge). The overall set of changes to be applied to the mainline is subject to review, and the commit message also is subject to review (review of commit messages isn't always something that PR-based systems seem to handle that well). But for the most part there isn't a need to rebase these - fixes as a result of review can go as subsequent commits on the source branch (making it easy to review either the individual fixes, or the whole updated set of changes), and merging from upstream into that branch is also OK. (If there *is* a rebase, the PR-based system should still preserve the history of and comments on previous versions, avoid GCing them and avoid getting confused.) * Complicated submissions of patch series, that are intended to end up as a sequence of commits on the mainline (non-squash merge preserving the sequence of commits). In this case, fixes (or updating from upstream) *do* involve rebases to show what the full new sequence of commits should be (and all individual commits and their commit messages should be subject to review, not just the overall set of changes to be applied). Again, rebases need handling by the system in a history-preserving way. GitHub (as an example - obviously not appropriate itself for the toolchain) does much better on simple submissions (either with squash merges, or with merges showing the full history if you don't care about a clean bisectable history), apart from review of commit messages, than it does on complicated submissions or dependencies between PRs (I think systems sometimes used for PR dependencies on GitHub may actually be third-party add-ons). Pull request systems have obvious advantages over mailing lists for tracking open submissions - but it's still very easy for an active project to end up with thousands of open PRs, among which it's very hard to find anything. -- Joseph S. Myers josmy...@redhat.com
Re: Updated Sourceware infrastructure plans
On Sat, 4 May 2024, Ben Boeckel via Gcc wrote: > - every push is stored in a ghostflow-director-side unique ref > (`refs/mr/ID/heads/N` where `N` is an incrementing integer) to avoid > forge-side garbage collection (especially problematic on Github; > I've not noticed GitLab collecting so eagerly) That's the sort of thing I was talking about for ensuring all the versions of every pull request remain available - it doesn't need anything more than providing such refs (that someone can get with git clone --mirror if they wish). (And there has been and is work on ensure git scales well to repositories with millions of refs, such as you get with PR-based systems storing all PRs or all versions of PRs as refs.) -- Joseph S. Myers josmy...@redhat.com
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
On 5/7/24 00:02, Toon Moene wrote: OK, perhaps on the aarch64 I need the following option to make the comparison fair: ‘rdma’ Enable Round Double Multiply Accumulate instructions. This is on by default for -march=armv8.1-a. I.e., -mno-rdma (I hope that's correct - I'll will try that when the Sun rises again and I have some power to run the AArch64 machine ...). Well, I did two independent runs with gfortran-13.2 and the following options: -O3 -march=armv8.1-a+rdma and -O3 -march=armv8.1-a+nordma No difference in the number of error runs exceeding the prescribed thresholds. So, unless I made a mistake in the option specification (or the compiler silently ignored them because they were not applicable to my machine - ugh), the cause of the problem lies elsewhere. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
On Tue, May 7, 2024 at 11:31 AM Toon Moene wrote: > > On 5/7/24 00:02, Toon Moene wrote: > > > OK, perhaps on the aarch64 I need the following option to make the > > comparison fair: > > > > ‘rdma’ > > > > Enable Round Double Multiply Accumulate instructions. This is on by > > default for -march=armv8.1-a. > > > > I.e., -mno-rdma > > > > (I hope that's correct - I'll will try that when the Sun rises again and > > I have some power to run the AArch64 machine ...). > > Well, I did two independent runs with gfortran-13.2 and the following > options: > > -O3 -march=armv8.1-a+rdma > > and > > -O3 -march=armv8.1-a+nordma > > No difference in the number of error runs exceeding the prescribed > thresholds. > > So, unless I made a mistake in the option specification (or the compiler > silently ignored them because they were not applicable to my machine - > ugh), the cause of the problem lies elsewhere. AARCH64 armv8-a has FMA as part of its base ISA. So you want to try with `-ffp-contract=off` instead. RDMA turns on/off instructions which are not used by the auto-vectorizer (yet) and used by intrinsics for them (If I read the code correctly). Thanks, Andrew Pinski > > Kind regards, > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands >
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
On 5/7/24 20:35, Andrew Pinski wrote: On Tue, May 7, 2024 at 11:31 AM Toon Moene wrote: On 5/7/24 00:02, Toon Moene wrote: OK, perhaps on the aarch64 I need the following option to make the comparison fair: ‘rdma’ Enable Round Double Multiply Accumulate instructions. This is on by default for -march=armv8.1-a. I.e., -mno-rdma (I hope that's correct - I'll will try that when the Sun rises again and I have some power to run the AArch64 machine ...). Well, I did two independent runs with gfortran-13.2 and the following options: -O3 -march=armv8.1-a+rdma and -O3 -march=armv8.1-a+nordma No difference in the number of error runs exceeding the prescribed thresholds. So, unless I made a mistake in the option specification (or the compiler silently ignored them because they were not applicable to my machine - ugh), the cause of the problem lies elsewhere. AARCH64 armv8-a has FMA as part of its base ISA. So you want to try with `-ffp-contract=off` instead. RDMA turns on/off instructions which are not used by the auto-vectorizer (yet) and used by intrinsics for them (If I read the code correctly). Ah, thanks - I'll try that tomorrow. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Products
Hello, We would like to purchase your product. Would you mind sharing your catalog with us? Thank you! Diane
